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I (57) Abstract: The invention relates to a method which enables 

a first message, particularly a multi-media message, preferably 
an sms type message, preferably sent via a moMe radio system 
and/or the internet to be manipulated, called back or altered 
by means of a second message sent after the first method^ 
/ User friendliness is increased for the user according to sard 

system The invention also relates to the possibility ot limited 
manipulation of a first message, as well as corresponding 
telecommunication devices, network elements and software 
programs. 

(57) Zusammenfassung: Es wird ein Verfahren verge stel It, 
das es ermoglicht, eine vorzugsweise uber ein MobUfunksystem 
und/oder das Internet versendete erste Nachricht, i^be^ere 
eine multimediale Nachricht, vorzugsweise vom MMS-lyp, 
mittels einer zeitlich nach der ersten Nachricht versendeten 
zweiten Nachricht zu manipulieren, beispielsweise ™ kzuru ; 
fen Oder zu andern. Hierdurch wird die Bedienerfreundhchkeit 
fur die Nutzer solcher Systeme erhoht. AuBerdem wird die 
Moglichkeit der bedingten Manipulation einer solchen ersten 
Nachricht vorgestellt. Des weiteren werden entsprechende 
Telekommunikationseinriehtungen, Netzwerkelemente sowie 
Softwareprogramme vorgeschlagen. 
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Be s chr e ibung 

Verfahren zum Zugreifen auf Nachrichten, entsprechende 
Vorrichtungen sowie Sof twareprogramme 

Die Erfindung betrifft ein Verfahren zum Zugreifen auf 
eine erste Nachricht, insbesondere eine multimediale 
Nachricht vorzugsweise vom MMS - Typ , wobei die erste Nach- 
richt mittelB einer Sendeapplikation oder einer VAS- 
10 Applikation an eine Empf angsapplikation gesendet wird. 

Des weiteren betrifft die Erfindung entsprechende Tele- 
kommunikationseinrichtungen, Netzwerkelemente scwie Soft- 

wareprogramme . 

Das Mobilfunksystem GSM (GSM - Global System for Mobile 
Communications) bietet neben der Sprachtelef onie auch die 
Moglichkeit, kurze Textnachrichten von bis zu 160 Zeichen 
Lange zu versenden bzw. zu empfangen. Dieser Dienst heiSt 
20 SMS (SMS - Short Message Service), s. GSM 03.40 version 
7.4.0, Release 1998; Digital Cellular Telecommunications 
System; Technical Realisation of the Short Message Servi- 
ce (SMS) . 

25 Fur das Mobilfunksystem der nachsten Generation UMTS 

(UMTS - Universal Mobile Telecommunication System) wird 
zur Zeit eine multimediaf ahige Variante eines mobilen 
Nachrichtendienstes standardisiert , der sogenannte MMS 
(MMS - Multimedia Messaging Service), s. 3G TS 22.140 

30 version 4.0.1, Release 2000; Third Generation Partnership 
Project; Technical Specification Group Services and Sys- 
tem Aspects; Service Aspects; Stage 1; Multimedia Messa- 
ging Service (MMS) . Nachrichten mit multimedialen Inhal- 
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ten werden im folgenden zur besseren Abgrenzung von den 
Textnachrichten des SMS nur noch kurz MMs (MM - Multime- 
dia Message; Plural: MMs) genannt . Im Gegensatz zum SMS 
entfallt die Beschrankung auf reine Textinhalte. Beim MMS 
5 wird es moglich sein, Texte dem individuellen Geschmack 
entsprechend zu formatieren sowie Audio- und Videoinhalte 
in eine Nachricht einzubetten. Eine weitere Neuigkeit 
ist, daS bei der Zustellung von MMs bekanntermafien zwi- 
schen dem sogenannten PUSH-Modus (Druck-/ Bring -Modus) , 
10 bei dem eine ankommende MM unverzuglich dem Empfanger zu- 
gestellt wird, und dem sogenannten PULL-Modus (Zieh-/Hol- 
Modus) , bei dem der Empfanger zunachst uber eine neu ein- 
getroffene MM informiert wird und daraufhin selbst ent- 
scheiden kann, wann er diese MM auf sein Endgerat herun- 
15 terladt, unterschieden wird. Diese bekannten Zusammenhan- 
ge sind in Fig. 1 verdeutlicht , wobei mit dem Bezugszei- 
chen 12 ein als MMS Server bezeichnetes Netzwerkelement 
und mit dem Bezugszeichen 11 ein UMTS Terminal gekenn- 
zeichnet ist. 

20 

Nach dem bisherigen Stand der Technik ist eine Implemen- 
tierung von MMS lediglich uber WAP {WAP - Wireless Appli- 
cation Protocol) realisierbar. Zur Uberbruckung der Luft- 
schnittstelle zwischen einem MMS-tauglichen Endgerat und 

25 dem WAP Gateway ist die Benutzung des WAP WSP (WSP - Wi- 
reless Session Protocol), s. WAP- 2 03 -WSP , Version 4-May- 
2000; Wireless Application Protocol, Wireless Session 
Protocol Specification; Chapter 8.4: "Header Encoding", 
vorgesehen, s. 3G TS 22.140 version 4.0.1 (s.o.); 3G TS 

30 23.140 version 4.0.0, Release 4, Third Generation Part- 
nership Project, Technical Specification Group Terminals, 
Multimedia Messaging Service (MMS) , Functional Descripti- 
on, Stage 2. 
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Fig. 2 zeigt ein sogenanntes Transaktions-FluEdiagramm 
nach heutigem Stand der Technik gemafc 3G TS 23.140 versi- 
on 4 . 0 . 0 (s.o.) , in dem der Austausch der WAP Nachrichten 

5 zwischen den drei beteiligten Instanzen beim Versand und 
Empfang einer MM dargestellt ist, namlich einer Sendeap- 
plikation UAA (UAA als Abkurzung fur MMS User Agent A) , 
Netzwerkelement RS (RS als Abkurzung MMS Relay/Server) 
und einer Empfangsapplikation UAB (UAB als Abkurzung fur 

10 MMS User Agent B) . Unter MMS User Agent versteht man 
hierbei eine Applikation auf einem Mobilf unkgerat oder 
auf einem an ein Mobilf unkgerat angeschlossenen Gerat 
(z.B. Laptop, o.a.), die MMS realisiert . Ein MMS Re- 
lay/Server ist ein Netzwerkelement im Zustandigkeitsbe- 

15 reicb bzw. in der MMS-Umgebung des MMS Dienstanbieters 

(MMS Service Providers), das den Applikationen „MMS User 
Agents- die MMS-Funktionalitat zur Verfugung stellt . 

Im folgenden wird anhand des bekannten Trans akt ions - 
20 FluSdiagramms in Fig. 2 ( „ Sendeapplikation UAA schickt 
MM A an Empfangsapplikation UAB«) der Austausch der WAP 
Nachrichten beschrieben. Dabei wird zunachst vereinfa- 
chend davon ausgegangen, daS die Sendeapplikation UAA 1 
und die Empfangsapplikation UAB 12 den MMS vom gleichen 
25 MMS Dienstanbieter in Anspruch nehmen. Die in des Sende- 
applikation UAA 1 erzeugte MM A wird mi t der WAP Nachricht 
M-Send.reg an das Netzwerkelement RS 2, 12 geschickt (da 
dieses Netzwerkelement sowohl senderseitig als auch emp- 
fangsseitige Funktionen ubernimmt, ist es mit dem doppel- 
30 ten Bezugszeichen 2, 12 gekennzeichnet ) . Daraufhin erhalt 
die Empfangsapplikation UAA 1 die WAP Nachricht M- 
Send.conf zurxick, mit welcher der korrekte Empfang der 
MM A vom Netzwerkelement RS 2 , 12 bestatigt wird. In ihr 
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ist auch eine vom Netzwerkelement RS 2, 12 festgelegte, 
moglicherweise individuelle , Identif ikationsnummer ID1 
fur die abgeschickte MM A enthalten. Danach informiert das 
Netzwerkelement RS 2 , 12 die Empf angsapplikation UAB 11 
5 mit der WAP Nachricht M-Notification.ind iiber den Spei- 
cherplatz (URI - Uniform Resource Identifier; im Folgen- 
den wird die Abkiirzung URI verwendet) der neu eingetrof- 
fenen und zum Herunterladen (Download) bereitliegenden 
MM A . Das Netzwerkelement RS 2, 12 erhalt daraufhin z.B. 
10 mit der WAP Nachricht M-NotifyResp. req eine Bestatigung, 
dafi die Benachrichtigung iiber die eingetrof f ene MM A (M- 
Notification.ind) erfolgreich zugestellt worden ist. Zu 
diesem Zeitpunkt hat das Netzwerkelement RS 2, 12 noch 
keine Nachrichten-ID filr die zum Herunterladen bereitlie- 
15 gende MM vergeben. Beim Austausch der beiden WAP Nach- 

xichten M-Notification.ind und M-NotifyResp . req wird nur 
eine fur diese Benachrichtigung individuelle Transakti- 
ons-Identitatsnummer (Transaction- ID) ausgetauscht . Die 
Empfangsapplikation UAB fordert dann mit Hilfe der WAP 
20 Nachricht WSP GET, mit welcher der URI an das Netzwerk- 
element RS 2, 12 geschickt wird, die Auslieferung der MM A 
an. Mit der WAP Nachricht M-Retrieve . conf wird der Emp- 
fangsapplikation UAB 11 daraufhin vom Netzwerkelement RS 
2, 12 die gevninschte MM A zugestellt . Hierbei wird die MM A 
25 iiber die vom Netzwerkelement RS 2 , 12 vergebene, mogli- 
cherweise individuelle, Identif ikationsnummer ID2 identi- 
fiziert. Mit der WAP Nachricht M-Acknowledge . ind wird der 
korrekte Empfang der MM A von der Empfangsapplikation UAB 
11 quittiert. Fur den Fall, daS der Absender den Wunsch 
30 geaufiert hat, iiber einen erf olgreichen Empfang der von 
ihm verschickten MM A benachrichtigt zu werden, kann das 
Netzwerkelement RS 2 , 12 dem nachkommen, indem die WAP 
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Nachricht M-Delivery. ind an die Empf angsapplikation UAB 
11 geschickt wird. 

Fig. 3 zeigt eine bekannte mogliche MMS Architektur, bei 
5 der die am Austausch einer MM beteiligten Sendeapplikati- 
on UAA 1 und Empfangsapplikation UAB 11 den MMS von ver- 
schiedenen MMS Dienstanbietern (MMS Dienstanbieter A und 
MMS Dienstanbieter B) in Anspruch nehmen. In diesem Fall 
ist eine Weiterleitung der MM zwischen den MMSEs (MMSE - 
Multimedia Messaging Service Environment = Multimedia- 
Nachrichtendienst-Umgebung bzw. MMS-Umgebung) der betei- 
ligten MMS Dienstanbieter notig. Das Bezugszeichen 4 
kennzeichnet die MMSE des MMS Dienstanbieters A und das 
Bezugszeichen 14 die MMSE des Dienstanbieters B. Die Wei- 
terleitung einer MM zwischen zwei MMSEs und hierbei ge- 
nauer zwischen dem senderseitigen Netzwerkelement RSA 2 
(RSA als Abkiirzung fur MMS Relay/Server A) und dem emp- 
fangsseitigen Netzwerkelement RSB 12 (RSB als Abkiirzung 
fur MMS Relay/Server B) geschieht iiber SMTP (SMTP - Simp- 
le Mail Transfer Protocol), s. 3G TS 23.140 version 4.0.0 
(s.o.), z.B. durch das Internet (IP - Internet Protocol 
mit Bezugszeichen 20). Das Protokoll SMTP ist in Fig. 3 
mit dem Bezugszeichen 22 bezeichnet . Das Mobilf unknetz 
wird in Fig. 3 wie allgemein iiblich als PLMN (PLMN - Pub- 
lic Land Mobile Network) bezeichnet und tragt in Fig. 3 
das Bezugszeichen 6. Jeder MM kann beim Editieren ein 
Zeitpunkt zugewiesen werden, zu dem die MM friihestens dem 
Empf anger, genauer der Empfangsapplikation UAB 11, zuge- 
stellt werden soil. Wird davon Gebrauch gemacht , ist eine 
Zwischenspeicherung der MM im senderseitigen MMSE A 4 - 
genauer: einem Speicher „MMS Server A" mit Bezugszeichen 
3 - bis zum Erreichen dieser Frist vorgesehen, s.o. Re- 
port of the 3 GPP TSG-T2 SWG3 MMS Ad Hoc Meeting #5 in So- 



20 



25 



30 



PCT7EP02/00571 

WO 02/063839 

6 

phia Antipolis, France 10-12 October 2000; T-doc: 
T2M00092; chapter 7; 3 GPP TSG-T2 SWG3 . Erst danach wird 
die MM an das empf angsseitige MMSE B 14 ubermittelt . Wei- 
terhin kann beim Editieren einer jeden MM auch eine ge- 

5 wiinschte Gultigkeitsdauer angegeben werden. Die Speiche- 
rung einer MM bis zum Ablauf der Gultigkeit bzw. bis zum 
vorherigen Download der MM durch die Empf angsapplikation 
UAB 11 soil im empfangsseitigen MMSE B 14 (genauer: in ei- 
nem Speicher .MMS Server B" rait Bezugszeichen 13) statt- 

10 finden, s.o. Report of the 3 GPP TSG-T2 SWG3 MMS Ad Hoc 
Meeting #5 . 

Wie ebenfalls aus der bekannten MMS Ref erenzarchitektur 
gemaS der Fig. 3 zu entnehmen ist, konnen die MMs nicht 
15 nur von Applikationen UAA bzw. UAB, sondern auch von MMS 
VAS-Applikationen (VAS Applications, wobei VAS = Value 
Added Services = Mehrwertdienste) stammen, die in der 
Fig. 3 mit dem Bezugszeichen 7 gekennzeichnet ist. Dabei 
handelt es sich urn eine netzwerkseitige Einrichtung, die 
20 Zusatzdienste anbietet . In diesem Fall dient die MM7- 
Schnittstelle als. Kommunikationsschnittstelle zwischen 
einer MMS VAS-Applikation und einem Netzwerkeleraent RS . 
Bis heute wurden fur diese Schnittstelle keine mandator! - 
schen MMS-spezif ischen Nachrichten definiert. Die Kommu- 
25 nikation hier kann auf HTTP (Hypertext Transport Proto- 
col) oder SMTP (Simple Mail Transport Protocol) basieren. 
Zudem ist es laut dem aktuellen Stand der Standardisie- 
rung moglich, eine MMl-ahnliche Kodierung fur diese 
Schnittstelle zu verwenden. 



30 



Bei den eingangs genannten Verfahren und Vorrichtungen 
ist eine Nachricht vom Absender bzw. Auftraggeber bear- 
beitbar, solange sie sich noch in der Sendeapplikation 
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UAA befindet. Wenn die Nachricht abgesandt wurde, besteht 
keine Moglichkeit der Bee influs sung bzw. des Zugreifens 
mehr. Dieses Problem besteht nicht nur bei der Versendung 
von Nachrichten uber Funk, sondern auch bei der Versen- 
5 dung von elektronischer Post (E-mails) liber das Internet 
und anderen Nachrichten- Systemen. 

Es ist Aufgabe der vorliegenden Erfindung, das Verfahren 
und die Vorrichtungen der eingangs genannten Art derart 
10 weiterzubilden, daS eine mehr den Bedurfnissen des Absen- 
ders/Empf angers orientiertere Bearbeitung bzw. Beeinflus- 
sung von Nachrichten ermoglicht wird. 

Diese Aufgabe wird bei dem Verfahren der eingangs genann- 
15 ten Art dadurch gelost, dalS eine zweite Nachricht mit ei- 
nem Manipulationsauf trag zur Manipulation der ersten 
Nachricht erstellt, versendet, empfangen, weitergeleitet 
und/oder verarbeitet wird, urn einen manipulierenden 
Zugriff auf die erste Nachricht zu veranlassen oder zu 
20 vermitteln. 

Weiterhin wird diese Aufgabe bei einer entsprechenden Te- 
lekommunikationseinrichtung durch die Merkmale des An- 
spruchs 35 gelost. Hierunter werden insbesondere Mobil- 

25 funktelefone sowie mit dem Internet verbundene Kommunika- 
tionseinheiten einschlieSlich Computer verstanden. Die 
erfindungsgemaSen Mittel zum Erstellen, Versenden, Emp- 
fangen und/oder Verarbeiten der zweiten Nachricht umfas- 
sen - neben den Hardwareeinheiten, wie insbesondere Steu- 

30 ereinheiten und Prozessoreinheiten - insbesondere Soft- 
warelosungen, die nachfolgend genauer vorgestellt werden 
und bevorzugt Modif ikationen von WAP -Nachricht en mit ver- 
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anderten und/oder neu definierten Kopf-Feldern darstellen 
bzw. diese verarbeiten konnen. 

Zudem wird diese Aufgabe bei einem entsprechenden Netz- 

5 werkelement durch die Merkmale des Anspruchs 46 gelost . 
im Sinne dieser Erfindung sind derartige Netzwerkelemente 
Teil eines Kommunikat ionssys terns , welche eine Kommunika- 
tion zwischen mehreren Sende- und/oder Empf angseinheiten, 
insbesondere mehreren Mobiltelef onen und/oder ans Inter - 

10 net angeschlossenen Rechnern, ermoglichen. Ein solches 

Kommunikationssystem - unter EinschluS von Funkkommunika- 
tionssystemen - wird iiblicherweise von Dienstanbieter 
bzw. Service Providern betrieben. Die erf indungsgemaSen 
Mittel zura Empfangen, Verarbeiten und/oder Weiterleiten 

15 der zweiten Nachricht schlieSen aufier den notwendigen 

Hardware-Elementen, wie insbesondere Steuereinheiten und 
Prozessoreinheiten, insbesondere Software ein, die im 
folgenden genauer beschrieben wird und bevorzugt Modifi- 
kationen von WAP -Nachricht en mit ensprechend angepaSten 

20 oder neu definierten Kopf-Feldern darstellen bzw. diese 
verarbeiten konnen. 

Eine Nachricht im Sinne dieser Erfindung kann sowohl eine 
herkommliche SMS, eine MM mit multimedialen Inhalten oder 

25 eine sonstige elektronische Nachricht sein. Im folgenden 
wird die Erfindung anhand der MM beschrieben, ohne daS 
hierdurch eine Einschrankung auf diesen Nachrichtentyp 
erfolgen soil. Fur die erste Nachricht wird im folgenden 
die Abkiirzung MM A , fur die zweite Nachricht die Abkurzung 

30 MM B verwendet . 



Die Vorteile der Erfindung liegen insbesondere darin, daS 
es ermoglicht wird, eine erste Nachricht nach dem Abschi- 
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cken zu manipulieren, insbesondere zuriickzuruf en und/oder 
nachtraglich eine Veranderung bzw. Aktualisierung an ihr 
vorzunehtnen. Eine solche Manipulation kann gemaS der Er- 
findung bei der Versendung von Nachrichten iiber Funk, u- 
5 ber Mobilfunksysteme, zwischen Mobilf unksystemen, insbe- 
sondere iiber ein Inter-Operator- IP-backbone , zwischen Mo- 
bilf unknetzen und anderen Nachrichten- Systemen, insbeson- 
dere Internet-Email, und/oder iiber das Internet moglich 
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30 



sein . 



insbesondere ist es mit Hilfe der vorliegenden Erfindung 
moglich, eine von einem Auftraggeber mittels einer Sende- 
applikation einer Sendeeinheit iiber mindestens ein Netz- 
werkelement an eine Empf angsapplikation einer Empfangs- 
einheit gesendete erste Nachricht - insbesondere eine 
Multimedia Message nach dem MMS-Typ - zu manipulieren, 
wobei nach Versenden der ersten Nachricht eine zweite 
Nachricht mit einer Manipulierinf ormation von der Sende- 
einheit an mindestens ein Netzwerkelement iibermittelt 
wird, das einen manipulierenden Zugriff auf die erste 
Nachricht veranlaSt oder vermittelt. 

Die erste Nachricht und die zweite Nachricht werden iiber 
mindestens ein senderseitiges Netzwerkelement eines 
Dienstanbieters und mindestens ein empf angerseitiges 
Netzwerkelement eines Dienstanbieters an die Empfangsap- 
plikation gesendet. Hierbei konnen das mindestens eine 
senderseitige Netzwerkelement und das mindestens eine 
empfangerseitige Netzwerkelement dem zustandigkeitsbe- 
reich eines einzigen Service Providers angehoren oder so- 
gar - im einfachsten Fall - identisch sein. 
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Auch sind Falle einer Identitat der Empfangs- und der 
Sendeapplikation moglich. 

Besonders bevorzugt erfolgt der manipulierende Zugriff 
5 auf die erste Nachricht auf einem senderseitigen Netz- 
werkelement, auf einem empf angerseitigen Netzwerkelement 
und/oder auf der Empf angsapplikation . 

1st die Empfangsapplikation noch nicht iiber den Manipula- 
10 tionsauftrag informiert worden, wird die erste Nachricht 
bevorzugt entweder im Zustandigkeitsbereich des sender- 
seitigen Oder des empf angerseitigen Dienstanbieters mani- 
puliert, vorzugsweise ohne die Empfangsapplikation iiber 
die Manipulation zu benachrichtigen. 1st die Benachrich- 
15 tigung iiber die erste Nachricht hingegen schon an die 
Empfangsseite erfolgt, aber ist diese erste Nachricht 
noch nicht heruntergeladen, wird vorzugsweise die erste 
Nachricht im Zustandigkeitsbereich des senderseitigen 
Dienstanbieters ohne Informieren der Empfangsapplikation 
20 manipuliert, oder die Manipulation erfolgt im Zustandig- 
keitsbereich des empf angerseitigen Dienstanbieters, wobei 
bevorzugt die Empfangsapplikation iiber die Manipulation 
und deren Zeitpunkt informiert wird. 

25 Die erf indungsgemaBe Manipulation ist nicht auf die bei- 
den Dienstmerkmale Zuriickrufen und Andern beschrankt . 
Auch Auftrage zu einer nachtraglichen Weiterleitung (For- 
warding) , ein nachtragliches Anhangen der zweiten Nach- 
richt an die erste Nachricht, usw. wird im Sinne dieser 

30 Erfindung unter einer Manipulation verstanden. Im folgen- 
den werden der Riickruf- und der Anderungsauf trag genauer 
beschrieben. 
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GemaS einer Ausfuhrungsf orm der Erfindung kann das Zu- 
riickrufen (im Rahmen dieser Offenbarung mit „Recall" be- 
zeichnet) einer MM zuraindest immer noch solange moglich 
sein, bis sie der Empf anger in einen anderen Ordner ver- 
5 schoben, an einen anderen Empf anger weitergeleitet oder 
geoffnet hat. 

Das nachtragliche Andern (im Rahmen dieser Offenbarung 
mit „Replace" bezeichnet) einer MM ist gemaS einer Aus- 

10 fuhrungsform der Erfindug vorteilhaf terweise auch dann 
noch moglich, wenn der Empf anger die MM schon „angefaSt" 
hat. in diesem Fall wird der Empf anger vorzugsweise umge- 
hend uber eine nachtragliche Anderung der entsprechenden 
MM informiert, entweder durch eine Benachrichtigung (No- 

15 tif ication) , damit er den Download der aktualisierten MM 
nachtraglich selbst einleiten kann (PULL-Modus) , oder 
gleich durch eine automatische Zustellung der aktuali- 
sierten MM (PUSH-Modus) . 

20 In einer Weiterbildung der Erfindung ist es zudem mog- 
lich, date der Absender einer MM, d.h. Sendeapplikation 
(MMS User Agent) oder MMS VAS-Applikation, eine zuvor 
verschickte MM unter Angabe bestimmter Bedingungen wieder 
zuriickrufen oder nachtraglich eine Veranderung bzw. Aktu- 

25 alisierung an ihr vornehmen kann. Diese vom Absender 

wahlbaren Bedingungen, die in Inf ormationselementen der 
zweiten Nachricht enthalten sind, konnen insbesondere 
sein: Ruckruf einer MM nur dann, wenn der Empf anger noch 
nicht uber eine zum Download bereitliegende MM informiert 

30 worden ist, oder Anderungsauf trag auch dann ausfuhren, 
wenn die MM schon an das Endgerat des Empfangers zuge- 
stellt, aber noch nicht geoffnet worden ist. Diese 
Dienstmerkmale werden im Folgenden „Bedingter Ruckruf" 
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(„ Conditional Recall" oder .Conditional Cancel") bezie- 
hungsweise „Bedingtes Andern" (.Conditional Replace") ge- 
nannt. Unter dem Begriff „Andern" bzw. „Replace" wird 
insbesondere das Ersetzen verstanden, aber auch jede 
5 sonstige Form des Anderns . Die erf indungsgemaEen Informa- 
tionselemente sind hierbei beispielsweise entsprechend 
erganzte oder neu definierte Kopf-Felder in WAP Nachrich- 
ten. 



10 



15 



20 



25 



30 



Vorteil dieses Erf indungsaspekts ist die Realisierung ei- 
ner Skalierbarkeit und Flexibility des Zuriickrufens 
und/oder des Ersetzens einer zuvor gesendeten MM. Diese 
Dienstmerkmale erhohen die Attraktivitat des Multimedia- 
Nachrichtendienstes (Multimedia Messaging Service) . 

Der Absender einer Nachricht (MM) - sowohl bei unbeding- 
ten als auch bei bedingten Manipulationsauf tragen - kann 
insbesondere eine Sendeapplikation „MMS User Agent" oder 
eine MMS VAS -Applikation sein. Eine solche Sendeapplika- 
tion kann zum Beispiel eine Applikation auf einem mobilen 
Endgerat sein, wahrend eine MMS VAS Applikation eine 
netzwerkseitige Applikation darstellt, die Mehrwertdiens- 
te anbietet. 

Des weiteren ist Gegenstand der Erfindung die Implemen- 
tierung des erf indungsgemaSen Verfahrens in WAP durch die 
Modifikation von vorhandenen Kopf-Feldern oder das Hinzu- 
fiigen von neu definierten Kopf-Feldern in die betroffenen 
WAP Nachrichten des WAP-MMSEncapsulation Standards, s. 
WAP-209-MMSEncapsulation, Release 2000; Wireless Applica- 
tion Protocol; WAP Multimedia Messaging Service; Message 
Encapsulation; MMS Proposed SCD 1.0. 
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Ebenso ist die entsprechende binare Kodierung, wie weiter 
unten fur Ausf uhrungsbeispiele beschrieben, Gegenstand 
der vorliegenden Erfindung. 

5 im folgenden wird die Erfindung anhand von Beispielen na- 
her erlautert . 

Es zeigen: 

10 Pig. 1 eine Gegeniiberstellung des PULL- und PUSH-Modus 
gema£ UMTS nach dem Stand der Technik ; 

Fig. 2 ein Transaktions-Diagramm fur einen Multimedia- 
Nachrichtendienst (MMS) nach dem Stand der 
25 Technik; 

Fig. 3 eine schematische Darstellung einer Multimedia- 
Nachrichtendienst-Architektur nach dem Stand 
der Technik; 

20 

Fig. 4 einen Multimedia-Nachrichtendienst mit einer 

Manipulationsmoglichkeit einer ersten Nachricht 
gemaS der vorliegenden Erfindung; 

25 Fig. 5 eine Kodierung von neu definierten Kopf- 
Feldern; 

Fig. 6 Erganzungen im bekannten Kopf-Feld X-Mms- 
Status; 

30 

Fig. 7 neu eingefiihrtes Kopf-Feld X-Mms -Original - 
Message -Sta tus ; 
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Fig. 8 neu eingefiihrtes Kopf-Feld X -Mms- Original - 
Message-ID; 

Fig. 9 Kodierung von weiteren neu definierten Kopf- 
Felder, und 

Fig. 10 Erganzungen im Kopf-Feld X -Mms- Supported - 
Feature. 

Es wird - unter Bezugnahme auf das obere Drittel der Fig. 
4 - bei der Beschreibung der Ausfiihrungsbeispiele von dem 
folgenden, bekannten Ablauf des Versendens und Empfangens 
einer ersten Nachricht MM A durch Vermittlung eines ersten 
und eines zweiten MMS Dienstanbieters (Dienstanbieter A 
und Dienstanbieter B) ausgegangen: Nach dem Verschicken 
der ersten Nachricht MM A wird der Sendeapplikation UAA 1 
des Absenders in der WAP Nachricht M-send.conf eine Mes- 
sage-ID fur die zuvor verschickte MM A mitgeteilt (ID1) . 
Diese identifikationsnummer ID1 wird vom Netzwerkelement 
RSA 2 des Dienstanbieters A erzeugt und kennzeichnet die 
MM A innerhalb der senderseitigen Schnittstelle Sendeap- 
plikation UAA 1 / Netzwerkelement RSA 2 eindeutig. Bei 
der empfangerseitigen Zustellung der MM A vom Netzwerkele- 
ment RSB 12 des Dienstanbieters B zur Empf angsapplikation 
UAB 11 durch die WAP Nachricht M-Retrieve . conf wird eben- 
■ falls eine Message-ID (ID2 in Fig. 2) ubermittelt . Diese 
Identifikationsnummer ID2 wird moglicherweise vom Netz- 
werkelement RSB 12 neu erzeugt und dient zur eindeutigen 
empfangerseitigen Kennzeichnung der MM A innerhalb der 
Schnittstelle Netzwerkelement RSB 12 / Empf angsapplikati- 
on UAB 11. 



Zur Ubermittlung der MM A zwischen dem senderseitigen 
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Netzwerkelement RSA 2 und dem empf angerseitigen Netzwerk- 
element RSB 12 kann ID1 in eine Interim- 
Identifikationsnummer (ID3) umgewandelt werden, welche 
die MM A zwischen den verschiedenen Systemen identif iziert 
(Aran.: in der Fig. 4 weisen generell die mit einem Stern - 
chen markierten Stellen auf solche Umwandlungen der Nach- 
richten-IDs zwischen den Schnitt stellen hin) . Insbesonde- 
re sollte ID3 global eindeutig sein. Z.B. enthalt ID3 In- 
formationen hinsichtlich des Dienstanbieters A, der ID1 
sowie dem Zeitpunkt der ID-Umwandlung . Dazu mufi das sen- 
derseitige Netzwerkelement RSA 2 die Information bzw. die 
Moglichkeit besitzen, diese Umwandlung wieder riickgangig 
zu machen, z.B. fur Auslief erungsberichte . Urn intern ii- 
bersichtliche IDs zu benutzen, kann ID3 vom empf angersei- 
tigen Netzwerkelement RSB 12 in die oben erwahnte interne 
ID2 umgewandelt werden, welche die MM A zu der Empfangsap- 
plikation UAB 11 identif iziert . Dazu muS wiederum das 
empfangerseitige Netzwerkelement RSB 12 die Information 
bzw. die Moglichkeit besitzen, diese Umwandlung wieder 
riickgangig zu machen, z.B. fur Auslief erungsberichte . Die 
MM A wird empfangerseitig durch ID2 identif iziert . 



GemaS der Erfindung wird nun von der Sendeapplikation, 
der Empfangsapplikation und/oder zwischen der Sende- und 

25 Empfangsapplikation vermittelnden Netzwerkelementen die 
Moglichkeit zum Zugriff auf die zuvor versendete erste 
Nachricht MM A bereitgestellt , indem eine zweite Nachricht 
MM B bereitgestellt wird, die einen manipulierenden 
Zugriff auf die erste Nachricht MM A veranlaSt oder ver- 

30 mittelt. 



Eine Moglichkeit der Identif ikation von MM B wird folgend 
anhand der Fig. 4 erlautert, bei der MM B die Identif ika- 
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tionsnummer ID4 tragt . Zur Ubermittlung von MM B zwischen 
den verschiedenen Dienstanbieter-Systemen kann ID4 vom 
senderseitigen Net zwerkelement RSA 2 umgewandelt werden 
in eine Interim- ID (ID6) , welche MM B zwischen den Syste- 
5 men identif iziert . Insbesondere sollte ID6 global eindeu- 
tig sein, z.B. eine Kombination von Inf ormationen hin- 
sichtlich des Dienstanbieters A, ID4 and Zeitpunkt der 
Umwandlung enthalten. Dazu muS das senderseitige Netz- 
werkelement RSA 2 die Information bzw. die Moglichkeit 
10 besitzen, diese Umwandlung wieder riickgangig zu machen, 

z.B. fur Auslieferungsberichte. Urn intern ubersichtliche- 
re IDs zu benutzen, kann ID6 vom empf angerseitigen Netz- 
werkelement RSB 12 umgewandelt werden in eine interne ID 
(IDS) , welche MM B zur Empf angsapplikat ion UAB 11 identi- 
15 f iziert. Dazu mufi das empf angerseitige Net zwerkelement 
RSB 12 die information bzw. die Moglichkeit besitzen, 
diese Umwandlung wieder riickgangig zu machen, z.B. fur 
Auslieferungsberichte. MM B wird empf angerseitig durch IDS 
identif iziert . 



20 



25 



30 



Urn die notwendige Verbindung von MM A und MM B zu realisie- 
ren, weist ID4 eine Referenz zu ID1, ID6 eine Referenz zu 
ID3 und ID5 eine Referenz zu ID2 auf . Die Benachrichti- 
gungen der Empf angsapplikation UAB 11 iiber MM A und MM B 
verweisen zudem auf zwei Speicherplatze URI1 bzw. URI2 . 

Es 1st moglich, da£ die Identif ikationsnummern ID1 und 
ID3, ID3 und ID2 , sowie ID1, ID2 und ID3 identisch sind. 
Ebenso konnen ID4 und ID6 , ID6 und IDS, sowie ID4 , IDS 
und ID6 identisch sein. 



Zumindest eines der beteiligten senderseitigen und ei: 
der beteiligten empf angerseitigen Netzwerkelmenente i 



10 
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vorteilhafterweise in der Lage, eine e ine indent ige, um- 
kehrbare Umwandlung von IDs vorzunehmen und die Informa- 
tionen hieriiber zu verwalten. 

5 im folgenden werden die Manipulationsmoglichkeiten „Riick- 
ruf w und „Andern« beispielhaft beschrieben, worunter un- 
ter dem letzteren Begriff im Sinne dieser Erfindung bei- 
spielsweise eine Aktualisierung der ersten Nachricht MM A 
verstanden wird, insbesondere durch Ersetzen der ersten 
Nachricht durch die zweite Nachricht. Allgemein sind je- 
doch alle Kombinationen der gemaS dieser Erfindung offen- 
barten Optionen fur alle Arten von Manipulationen reali- 
sierbar, so z.B. ob und mit welchen Inf ormationen der 
Empfanger uber eine Manipulation einer ersten Nachricht 
benachrichtigt wird, ob uber die Art der Manipulation in- 
formiert werden soil, ob der Empfanger iiber einen Manipu- 
lationswunsch des Absenders informiert werden soil, ob 
die zweite Nachricht im PULL- oder im PUSH-Modus zuge- 
stellt werden soli, ob die Anderung auf einem sendersei- 
tigen oder empf angerseitigen Netzwerkelement oder auf der 
Empfangsapplikation UAB erfolgen soli, ob der Absender 
und/oder der Empfanger iiber den Erfolg der Manipulation 
benachrichtigt werden soil, usw. 



15 



20 



25 



A. DIENSTMERKMAL „RUCKRUF , 



GemaS der Erfindung kann ein Benutzer des MMS, der eine 
erste Multimedia Message MM A abgeschickt hat und diese 
30 bereits verschickte MM A wieder zuruckrufen mochte, eine 
neue, zweite' Nachricht MM B mit der Information verschi- 
cken, da£ die zuvor verschickte, erste Nachricht MM A wie- 
der zurilckgeruf en werden soil . 
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Dies kann erf indungsgemaE bevorzugt dadurch realisiert 
werden, indem der Absender die neue MM B verfaSt, die ei- 
nen Ruckruf -Bef ehl , aber bevorzugt keinen fur den Empf an - 

5 ger bestimmten Inhalt (Content /Message Body) , beinhaltet, 
und diese an den gleichen Empfanger wie die zuvor ver- 
schickte MM A schickt. Als Ruckruf -Kennung wird bevorzugt 
die ID1 der zuvor verschickten MM A benutzt. Die MM B mit 
der Ruckruf -Information gelangt zunachst zum Netzwerkele- 

10 ment RSA des Absenders . Hier wird zweckmafiigerweise liber- 
pruft, ob die MM A mit der ID1 noch im Zustandigkeitsbe- 
reich des Dienstanbieters A (MMSE A ) ist, oder ob sie 
schon an das MMSE B des Dienstanbieters B weitergeleitet 
worden ist. Ersteres ist z.B. der Fall, wenn der vom Ab- 

15 sender gewahlte Zeitpunkt fur die gewunschte Zustellung 
seiner MM A noch nicht erreicht worden ist; letzteres ist 
z.B. der Fall, wenn die MM A noch nicht ihre Gultigkeits- 
dauer uberschritten hat und noch nicht der Empf angsappli- 
kation UAB zugestellt worden ist. Sobald die MM A in einem 

20 MMSE der beteiligten MMS Dienstanbieter ausfindig gemacht 
wird, kann das Loschen von MM A und MM B vom zustandigen 
Netzwerkelement RS eingeleitet werden. 

Falls die Empf angsapplikatin UAB schon iiber die fur ihn 
25 im MMSE B bereitliegenden MM A mittels einer Benachrichti- 
gung (Notification) informiert worden ist und sich die 
MM A noch im Zustandigkeitsbereich/Speicher des Dienstan- 
bieters B befinden sollte, kann nach dieser Erfindung die 
Empf angsapplikation UAB mit einer erneuten Benachrichti- 
30 gung (Notification) davon in Kenntnis gesetzt werden, daS 
die MM A vom Dienstanbieter B geloscht worden ist und so- 
mit nicht mehr zum Download bereit liegt, well der Absen- 
der sie zuruckgeruf en hat. Aufierdem hat der MMS Dienstan- 
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bieter B nach dieser Erfindung die Moglichkeit, der Emp- 
fangsapplikation UAB das Datum der Ausfiihrung des Riick- 
ruf -Befehls zu iibermitteln. 

5 Sollte die MM A schon an den Empf anger ausgelief ert worden 
sein, so kann die Empf angsapplikat ion UAB des Empfangers 
mit der o.g. erneuten Benachrichtigung (Notification) da- 
von in Kenntnis gesetzt werden, daS der Absender die MM A 
zuriickrufen mochte . Das Loschen der MM A kann nach dieser 

10 Erfindung direkt in der Empf angsapplikation UAB stattfin- 
den, sofern dieses das Ruckruf -Dienstmerkmal unterstutzt. 
Je nach Implement ierung dieses Dienstmerkmal s im Endge- 
rat, den Einstellungen des Benutzers, den Einstellungen 
des MMS Dienstanbieters und/oder des Netzbetreibers kann 

15 das Loschen der MM A im Endgerat davon abhangig sein, ob 
die MM A bereits vom Empf anger „angefafit" (z.B. geoffnet, 
gelesen, weitergeleitet , etc.) worden- ist . Sinnvoll er- 
scheint jedoch, nur solche MMs nach der Auslieferung zu 
loschen, welche noch nicht vom Empf anger „angefa£t u wor- 

20 den sind. Die MM B mit der Riickruf -Information muS der 

Empfangsapplikation UAB nicht unbedingt zugestellt wer- 
den; sie kann schon im MMSE B geloscht werden. 

Hat der Empf anger (MMS User Agent B) der MM A noch keine 
25 Benachrichtigung uber die MM A erhalten, etwa weil die MM B 
mit der Riickruf -Information das Netzwerkelement RSB vor 
der rtickzuruf enden MM A erreicht, muS dieser auch nicht 
liber eine vom Absender eingeleitete Riickruf -Akt ion infor- 
miert werden. Statt dessen wartet das Netzwerkelement RSB 
30 vorzugsweise, bis es die zum Riickruf ref erenzierte MM A 

erhalt und loscht diese beim Eintreffen, ohne den Empfan- 
ger zu benachrichtigen (vorausgesetzt , das Netzwerkele- 
ment RSB unterstutzt das Riickruf -Dienstmerkmal) . Alterna- 
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tiv kann die Loschung von MM A auch schon auf dem Netz- 
werkelement RSA erfolgen. 

Der Auftraggeber des Ruckruf s (MMS User Agent A) wird ge- 
5 maS. der vorliegenden Erf indung uber den Ausgang und das 
Datum der Ausfiihrung der von ihm eingeleiteten Aktion 
vorzugsweise informiert, wenn die beteiligten MMS Dienst- 
anbieter dies ermoglichen. 

10 Urn das gerade beschriebene Dienstmerkmal Ruckruf umsetzen 
zu konnen, schlagt die vorliegende Erf indung vor, daS ei- 
ne oder mehrere der folgenden Inf ormationen zusatzlich 
zwischen den beteiligten Instanzen (Sendeapplikation UAA, 
Netzwerkelement RSA, Netzwerkelement RSB und Empfangsap- 

15 plikation UAB) ausgetauscht werden: 

Sendeapplikation UAA (MMS User Agent A) -» Netzwerkele- 
ment RSA (MMS Relay/Server A) (beim Versenden einer MM) : 

• Kennzeichnung, daS es sich bei einer MM B urn einen 
20 Ruckruf -Befehl handelt. 

• Identif ikationsnummer der MM A/ die zuruckgeruf en wer- 
den soli. 

• Information, dafi der Absender eine Ruckmeldung uber 
den Ausgang der von ihm initiierten Ruckruf -Aktion an- 

25 f ordert . 



Netzwerkelement RSA (MMS Relay/Server A) -» Sendeapplika- 
tion UAA (MMS User Agent A) (bei der Bestatigung nach dem 
Versendens einer MM) : 
30 • Mitteilung des Dienstanbieters , ob dieser das Ruckruf - 
Dienstmerkmal unterstutzt. 
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Netzwerkelement RSA (MMS Relay/Server A) Netzwerkele- 
ment RSB (MMS Relay/Server B) (nur dann notig, wenn Ab- 
sender und Empfanger zu unterschiedlichen MMSEs gehoren) 

• Kennzeichnung, da£ es sich bei einer MM B urn einen 
5 Ruckruf -Bef ehl handelt . 

• identifikationsnummer der MM A , die zuruckgeruf en wer- 
den soil. 

• Information, daS der Absender eine Riickmeldung iiber 
den Ausgang der von ihm initiierten Ruckruf -Akt ion an- 

10 f ordert . 

Die Ubermittlung der Inf ormationen zwischen Netzwerkele- 
ment RSA und Netzwerkelement RSB ist davon abhangig, ob 
diese Inf ormationen beim Versenden der MM B vorhanden wa- 
ren. 

15 

Netzwerkelement RSB (MMS Relay/Server B) -> Empfangsap- 
plikation UAB (MMS User Agent B) (bei der Benachrichti- 
gung iiber eine eingetrof f ene MM) , vorzugsweise in einer 
Nachricht : 

20 • Information, wann der Ruckruf ausgefuhrt wurde. 

• Information, dafi eine zuvor durch eine Benachrichti- 
gung angekiindigte MM A nun nicht mehr zum Download be- 
reitliegt. Identif izierung der MM A , die im MMSE B ge- 
loscht worden ist, erfolgt anhand der Nachrichtenref e 

25 renz (Message Reference ; URI) . 

oder: 

• Information, daE eine bereits ausgelief erte MM A vom 
Absender zuruckgeruf en wird. Identif izierung der MM A , 
die zuruckgeruf en wird, erfolgt auf der Empf angsappli 

30 kation UAB anhand der Nachrichten-ID . 
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Empfangsapplikation UAB (MMS User Agent B) -» Netzwerk- 
element RSB (MMS Relay/Server B) (nach der Benachrichti- 
gung) : 

• Information, ob der Empf anger verstanden hat, daS eine 
5 zuvor durch eine Benachrichtigung angekiindigte MM A nun 

nicht raehr zura Download bereitliegt . 
oder .- 

• Information, ob die Empfangsapplikation UAB den Riick- 
ruf (d.h. das Loschen) der MM A erfolgreich durchfiihren 

10 . konnte bzw. veranlaSt hat. 

• information, ob der Empf anger dariiber informiert wurde 
(und/oder dem Riickruf zugestimmt hat) , daS eine be- 
reits heruntergeladene MM A zuriickgeruf en wurde und da- 
her nicht mehr im der Empfangsapplikation UAB zugang- 

15 lichen Speicher des Endgerats (oder angeschlossener 

Gerate/Speicherkarten) vorliegt. 

Netzwerkelement RSB (MMS Relay/Server B) -» Netzwerkele- 
ment RSA (MMS Relay/Server A) (nur dann notig, wenn Ab- 
20 sender und Empfanger zu unterschiedlichen MMSEs gehoren 
und wenn der Absender eine Ruckmeldung angefordert hat) : 

• Information, ob der Riickruf -Auft rag erfolgreich ausge- 
f uhrt werden konnte . 

• Information, wann der Riickruf -Auftrag ausgefiihrt wor- 
25 den ist. 

• Information, ob der Riickruf -Auftrag automatisch durch- 
gefiihrt wurde. 

• Information, ob der Empfanger iiber den Riickruf infor- 
miert wurde (und/oder dem Riickruf zugestimmt hat) . 

30 • Information, daS eine bereits heruntergeladene MM A zu- 
riickgerufen wurde und daher nicht mehr im der Emp- 
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fangsapplikation UAB zugangigen Speicher des Endgerats 
(oder angeschlossener Gerate/Speicherkarten) vorliegt. 

• Identif ikationsnummer der MM A , die zuruckgeruf en wur- 
de . 

5 

Netzwerkelement RSA (MMS Relay/Server A) Empfangsap- 
plikation UAA (MMS User Agent A) (beim Bericht) : 

• Information, ob der Ruckruf -Auf trag erfolgreich ausge- 
f uhrt werden konnte . 

10 • Information, wann der Ruckruf -Auf trag ausgefiihrt wor- 
den ist. 

• Information, ob der Ruckruf -Auf trag automatisch durch- 
gef tihrt wurde , 

• Information, ob der Empf anger uber den Ruckruf infor- 
15 miert wurde (und/oder dem Ruckruf zugestimmt hat) . 

• Information, daS eine bereits heruntergeladene MM A zu- 
riickgeruf en , wurde und daher nicht mehr im der Emp- 
fangsapplikation UAB zugangigen Speicher des Endgerats 
(oder angeschlossener Gerate/Speicherkarten) vorliegt. 

20 • Identif ikationsnummer der MM A , die zuruckgeruf en wur- 
de ♦ 

Zusatzliches Dienstmerkmal: Bedingter Ruckruf 

25 

Diesem speziellen Erf indungsaspekt liegt die Idee eines 
bedingten Zuruckruf ens (,, Conditional Recall/Cancel") und 
bedingten Anderns bzw. Ersetzens oder Aktualisierens von 
Multimedia-Nachrichten („Conditional Replace") zugrunde . 
30 Erf indungsgemaE wird die Ausfuhrung eines vom Absender 
einer MM nachtraglich verschickten Ruckruf- oder Ande- 
rungsauf trages an bestimmte Bedingungen gekniipft. Zum 
Beispiel kann es sein, daS Absender eine bestimmte MM nur 
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dann zuruckrufen oder aktualisieren will, wenn der Emp- 
f anger noch nicht iiber das Eintreffen informiert wurde. 
In anderen Fallen konnte er das Loschen oder das Andern 
wiinschen, auch wenn die Empf angsapplikation UAB eine Be- 

5 nachrichtigung (Notification) erhalten hat oder wenn die 
MM sogar gelesen wurde. Des weiteren ist ein Konzept zur 
Realisierung dieser Dienstmerkmale Teil dieser Erfindung, 
bei dem die Einfuhrung bzw. Anpassung von Datenf elder aus 
der 3GPP MMS Spezif ikation notwendig ist, s.o. 3G TS 

10 23.140 version 4.0.0. Dabei werden neue Kopf-Felder der 
WAP Nachrichten definiert und andere Felder angepaSt oder 
erganzt . 

GemaS dieser bevorzugten Ausfiihrungsf orm der Erfindung 
15 kann eine zweite Nachricht, im folgenden MM B genannt, mit 
der Information verschickt werden, dafi die erste Nach- 
richt, d.h. MM A , unter bestimmten Konditionen annulliert 
bzw. zuriickgerufen werden soli. Die neue MM B beinhaltet 
Informationen zum Ausfiihren des Vorgangs des Zuruckrufens 
20 der MM A . Erf indungsgemaS setzt der Absender des Ruckruf - 
Befehls Bedingungen zum Ausfiihren seines Wunsches . Dabei 
legt der sendende User Agent oder die VAS-Appl ikation 
fest, in welchem Fall die zuvor gesendete MM geloscht 
bzw. ungultig gemacht werden soli. 



25 



30 



Der Dienstanbieter kann erf indungsgemaS das Verwenden des 
Ruckruf -Merkmals auf die eigene oder auf bestimmte Doma- 
nen anderer Dienstanbieter begrenzen. Dies kann anhand 
einer Identif izierung der Adresse des Empf angers, bei- 
spielsweise seiner Rufnummer, Mailadresse o.a., erfolgen. 
Eine weitere Moglichkeit ware das Einsetzen einer zusatz- 
lichen Kennzeichnung (Flag) in dem Ruckruf -Befehl . 
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Im weiteren basiert cier bedingte Riickruf auf die Bearbei- 
tungsphase bzw. den Bearbeitungszustand der zuvor gesen- 
deten Nachricht, insbesondere einer MM. Der Absender ent- 
scheidet in diesem Fall, in welchem Zustand der MM diese 
5 geloscht werden soil. Mogliche vom Absender festgelegte 
Konditionen fur den Riickruf konnen insbesondere sein: 

1. Zuriickrufen der MM riur, wenn die MM noch auf dem Ser- 
ver liegt und der Empf anger davon noch nicht in Kennt- 

0 nis gesetzt wurde. Der Riickruf erfolgt in diesem Fall 

also nur, wenn noch keine Benachrichtigung (Notifica- 
tion) gesendet wurde. 

2. Zuruckrufen der MM auch dann, wenn die Benachrichti- 
5 gung (Notification) gesendet, aber die MM noch nicht 

heruntergeladen wurde. 

3. Zuruckrufen der MM, wenn der Empf anger diese noch 
nicht geoffnet bzw. gelesen hat. In diesem Fall kann 

0 das Zuruckrufen auch nach dem Herunterladen erfolgen. 

4 . Zuruckrufen der MM unabhangig vom Bearbeitungsgrad der 
MM beim Empf anger. Der Riickruf wird hier auch dann 
versucht, wenn der Empf anger die MM gelesen hat. 

5 

Bei der Realisierung dieser Dienstmerkmale wird vorteil- 
hafterweise eine Standardkondition ;/ Default value" ange- 
nommen. Zum Beispiel kann vereinbart werden, daS eine 
Standardkondition einem der oben beschriebenen vier Falle 
0 entspricht. Diese Voreinstellung kann beispielsweise - 
solange nichts Genaues zum konditionellen Ausfiihren des 
Riickruf -Befehls geauSert wurde - derart festgelegt sein, 
daS das Zuruckrufen zum Beispiel nur vor einer Benach- 
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richtigung uber das Vorliegen einer MM erfolgen soil. Das 
System konnte auch so ausgelegt sein, daS ein Zuriickrufen 
nur vor dem Herunterladen der zu loschenden MM oder sogar 
nach erfolgtem Offnen bzw. Lesen der MM erfolgen soil. 

5 

Im folgenden werden die Transaktionen zur Realisierung 
vom MM- Status -bedingten Ruckruf -Merkmals behandelt. 
Eine bereits verschickte MM A kann also durch den Absender 
nachtraglich wieder zuruckgeruf en werden, indem er eine 

10 neue MM B verfaSt, die einen bedingten Ruckruf befehl , aber 
bevorzugt keinen fur den Empfanger bestimmten Inhalt 
(Content/Message Body) beinhaltet. Diese neue Nachricht 
wird dem gleichen Empfanger wie die zuvor verschickte MM A 
gesendet. Als Ruckruf kenniang wird bevorzugt die Identifi- 

15 kationsnummer (ID 1) der zuvor verschickten MM A benutzt . 
Die MM B mit der Ruckruf - Information gelangt zunachst zum 
Netzwerkelement RSA (MMS Relay/Server A) des Absenders. 
Hier wird uberpruft, ob die MM A mit der ID 1 noch im Zu- 
standigkeitsbereich des Dienstanbieters A (Multimedia 

20 Messaging Service Environment A, MMSE A ) ist, oder ob sie 
schon an das MMSE B des Dienstanbieters B weitergeleitet 
worden ist. Ersteres ist z.B. der Fall, wenn der vom Ab- 
sender gewahlte Zeitpunkt fur die gewunschte Zustellung 
seiner MM A noch nicht erreicht worden ist; letzteres ist 

25 z.B. der Fall, wenn die MM A noch nicht ihre Giiltigkeits- 
dauer iiberschritten hat und noch nicht der Empf angsappli- 
kation UAB zugestellt worden ist. 

Sobald die MM A in einem MMSE ausf indig gemacht wird, kann 
30 das Loschen von MM A und MM B vom zustandigen Netzwerkele- 
ment RS eingeleitet werden. Falls der urspriingliche Emp- 
fanger die an ihn adressierte MM A an eine andere Adresse 
weitergeleitet hat, soil bevorzugt auch der Ruckruf befehl 
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vom Netzwerkelement RSB entsprechend weitergeleitet wer- 
den, womit das Zuruckrufen im zielseitigen Netzwerkele- 
ment RS erfolgen kann. Wenn das Netzwerkelement RSB nur 
die Information hat, daS die MM weitergeleitet wurde, oh- 
5 ne das Ziel zu wissen (beispielsweise , wenn der ursprung- 
liche Empfanger die an ihn adressierte MM an eine E-mail 
Adresse weitergeleitet hat) , kann der Absender des Riick- 
rufbefehls vorteilhaf terweise liber den MiSerfolg des 
Ruckrufs aufgrund des Weiterleitens informiert werden. 
10 Aus Vertraulichkeitsgriinden ware es auch moglich, den Mi- 
Serfolg der Ausfuhrung zu melden, ohne in diesem Fall den 
Grund zu kommentieren. 

Ein besonders giinstiger Fall zum Ausfiihren des Riickrufbe- 
15 fehls liegt vor, wenn die MM noch auf einem der Netzwerk- 
elemente RSA oder RSB, und die Empf angsapplikation UAB 
noch nicht uber diese Nachricht benachrichtigt wurde. Ein 
solcher Fall konnte zum Beispiel auftreten, wenn die MM 
auf Wunsch des Absenders zu einem bestimmten Zeitpunkt 
20 ausgeliefert werden soil, der aber noch nicht eingetreten 
ist. Hier liegt die MM noch auf dem Netzwerkelement RSA 
des Absenders . Die MM kann auch auf dem Netzwerkelement 
RSB gespeichert sein, falls z.B. das Endgerat des Empf an- 
gers ausgeschaltet ist und die Giiltigkeitsdauer der MM 
25 nicht uberschritten wurde. In diesen beiden Fallen kann 

das Loschen der MM unabhangig von den ausgewahlten Losch- 
konditionen erfolgen. Alle vier oben beschriebenen Ruck- 
ruf konditionen decken namlich diese Situation ab. 

30 Falls die Empf angsapplikation UAB schon liber die fur ihn 
im MMSE B bereitliegende MM A mittels einer Benachrichti- 
gung (Notification) informiert worden ist und sich die 
MM A noch im Zustandigkeitsbereich/Speicher des Dienstan- 
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bieters B befinden sollte, kann gemaS dieser Erfindung 
das Zuruckrufen nur in den oben mit 2, 3 und 4 numerier- 
ten Fallen erfolgen. Fur den Fall 1 des bedingten Ruck- 
rufs erhalt der Absender vorzugsweise eine Benachrichti- 
5 gung mit der Erklarung, daS der Empf anger schon uber die 
zuvor gesendete MM informiert wurde und das Zuruckrufen 
nicht durchgefuhrt werden konnte. Fur die weiteren Falle 
(2, 3 und 4) kann die Empf angsapplikation UAB mit einer 
erneuten Benachrichtigung (Notification) davon in Kennt- 
10 nis gesetzt werden, daS die MM A vom Dienstanbieter B ge- 
loscht wurde und somit nicht mehr zum Herunterladen be- 
reit liegt, weil der Absender sie zuruckgeruf en hat. Eine 
weitere Moglichkeit ware, den Empf anger liber den Riickruf- 
vorgang zu informieren, und erst wenn er die MM anf or- 
is dert, ihm mitzuteilen, daiS sie nicht mehr vorhanden ist, 
oder das sie zuruckgeruf en wurde. 

Sollte die MM A schon an den Empfanger ausgeliefert worden 
sein, so kann das Zuruckrufen nur fur den Fall 4 (Zuriick- 

20 rufen, unabhangig vom Bearbeitungsgrad) und unter Urns tan - 
den fur den Fall 3 (Zuruckrufen, wenn MM noch nicht ge- 
6f f net/gelesen wurde) erfolgen. Die Empf angsapplikation 
UAB wird - nur fur die Falle 3 und 4 - vorzugsweise mit 
einer neuen Benachrichtigung (Notification) davon in 

25 Kenntnis gesetzt, da£ der Absender die MM A zuruckrufen 
mochte. Diese Benachrichtigung beinhaltet bevorzugt die 
Konditionen des Loschens . 

Das Loschen der MM A kann folglich direkt in der Empfangs- 
30 applikation UAB stattfinden, sofern dieses das Ruckruf- 
Merkmal unterstutzt. Wenn es sich urn den Fall 3 handelt, 
wird die MM nur dann geloscht, wenn das Endgerat fest- 
stellt, daS die MM noch nicht geoffnet bzw. gelesen wur- 
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cie. Fur den Fall 4 wird das Loschen unabhangig davon ve- 
ranlaSt. In beiden Fallen muS die MM B der Empf angsappli- 
kation UAB nicht zugestellt werden. Sie kann schon im 
MMSE B geloscht werden, da die Benachrichtigung (Notifica- 
5 tion) der Ausloser des Loschens ist. Fur die Falle 1 

(Ruckruf vor der Benachrichtigung) und 2 (Ruckruf nur vor 
dem Herunterladen) kann der Ruckruf nicht erfolgen. Der 
Absender erhalt hierbei vorzugsweise eine Ruckmeldung mit 
der Information, dafi die MM nicht zuruckgeruf en werden 
10 konnte, da eine Benachrichtigung schon abgeschickt wurde 
(Fall 1) oder weil die MM schon heruntergeladen wurde 
(Fall 2) . 

Eine weitere Moglichkeit zur Realisierung des Loschvor- 
15 gangs ist erf indungsgemaS das Zustellen der MM B mit der 
Ruckruf -Information bis zur Empf angsappli kation UAB. Das 
Loschen wird dann im Endgerat des Empf angers durch die 
MM B und nicht durch die aus der MM B entstehende Benach- 
richtigung (Notification) ausgelost . Dieser Fall wird im 
20 weiteren nicht detaillierter behandelt. 

Der Auftraggeber des Ruckruf s (Sendeapplikation UAA oder 
VAS Applikation) wird bevorzugt in alien beschriebenen 
Fallen liber den Ausgang und ggf . das Datum der Ausf uhrung 
25 der von ihm eingeleiteten Aktion informiert, insbesondere 
wenn er dies anfordert und zudem die beteiligten MMS 
Dienstanbieter dies ermoglichen. 

Urn das gerade beschriebene Dienstmerkmal „Bedingter Ruck- 
30 ruf u umsetzen zu konnen, wird erf indungsgemafi vorgeschla- 
gen, daS eine oder mehrere der folgenden Inf ormationen 
zusatzlich zwischen den beteiligten Instanzen (Sendeap- 
plikation UAA , MMS Netzwerkelement RSA, MMS Netzwerkele- 
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ment RSB und Empf angsapplikation UAB) ausgetauscht wer- 
den. Als Basis dienen die aktuellen 3 GPP Spezif ikationen 
3G TS 22.140 version 4.0.1 (s.o.), 3G TS 23.140 version 
4.0.0 (s.o.), WAP Spezif ikationen WAP-209- 
5 MMSEncapsulation, Release 2000 (s.o.), WAP-203-WSP, Ver- 
sion 4-May-2 000 (s.o.) sowie Report of the 3GPP TSG-T2 
SWG3 MMS Ad Hoc Meeting #5 (s.o.) . Im Folgenden wird na- 
her auf die Unterschiede und Erganzungen im Vergleich zu 
dem unbedingten Ruckruf eingegangen: 

10 

Sendeapplikation UAA (MMS User Agent A) -> Netzwerkele- 
ment RSA (MMS Relay/Server A) (beim Versenden einer MM) : 
• Bedingungen zum Ausfuhren des Ruckruf s : 

- Ruckruf nur vor Benachrichtigung . 

15 - Ruckruf nur vor dem Herunterladen, auch nach dem Ver- 

sand einer Benachrichtigung . 

- Ruckruf nur, wenn die MM nicht geof f net/gelesen wur- 
de. 

- Ruckruf unabhangig vom Bearbeitungsgrad der MM (auch 
20 nach dem Lesen der MM A ) . 

Netzwerkelement RSA (MMS Relay/Server A) — > Sendeapplika- 
tion UAA (MMS User Agent A) (bei der Bestatigung nach dem 
Versenden einer MM) : 
25 • Mitteilung des Dienstanbieters , ob dieser das bedingte 
Ruckruf -Merkmal unterstiitzt. Hier konnte das System 
zwischen der Unterstutzung fur „Ruckruf w und „Bedingter 
Ruckruf * unterscheiden. 

30 Netzwerkelement RSA (MMS Relay/Server A) — > Netzwerkele- 
ment RSB (MMS Relay/Server B) (nur dann notig, wenn Ab- 
sender und Empf anger zu unterschiedlichen MMSEs gehoren) : 
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• Bedingungen zum Ausfiihren des Riickrufs: 

- Ruckruf nur vor Benachrichtigung . 

- Ruckruf nur vor dem Herunterladen, auch nach dem Ver- 
sand einer Benachrichtigung 

5 - Ruckruf nur, wenn die MM nicht gelesen wurde . 

- Ruckruf unabhangig vom Bearbeitungsgrad der MM (auch 
nach dem Lesen) . 

Netzwerkelement RSB (MMS Relay/Server B) -» Empfangsap- 
10 plikation UAB (MMS User Agent B) (bei der Benachrichti- 
gung iiber die eingetrof f ene MM B ) : 

• Bedingungen zum Ausfiihren des Ruckruf s: 

- Ruckruf nur vor dem Herunterladen, auch nach dem Ver- 
sand einer Benachrichtigung. Diese Bedingung wird nur 

15 dann mitgeteilt, wenn die MM nicht heruntergeladen 

wurde . 

- Ruckruf nur, wenn die MM nicht gelesen wurde. 

- Ruckruf unabhangig vom Bearbeitungsgrad der MM (auch 
nach dem Lesen) . 

20 

Empf angsapplikation UAB (MMS User Agent B) -» Netzwerk- 
element RSB (MMS Relay/Server B) (nach der Benachrichti- 
gung) : 

• Information, ob der bedingte Ruckruf -Auftrag erfolg- 
25 reich ausgef iihrt werden konnte . 

• Bei MiSerfolg entsprechende Meldung mit einer moglichen 
Begriindung . 

Netzwerkelement RSB (MMS Relay/Server B) -> Netzwerkele- 
30 ment RSA (MMS Relay/ Server A) (nur dann notig, wenn Ab- 
sender und Empf anger zu unterschiedlichen MMSEs gehoren 
und wenn der Absender eine Ruckmeldung angefordert hat) : 
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• Information, ob der bedingte Ruckruf ~Auf trag erfolg- 
reich ausgefiihrt werden konnte. 

• Bei Mifierfolg entsprechende Meldung mit einer moglichen 
Begriindung. 

5 

Netzwerkelement RSA (MMS Relay/Server A) -» Sendeapplika- 
tion UAA (MMS User Agent A) (beim Report) : 

• Information, ob der bedingte Ruckruf -Auf trag erfolg- 
reich ausgefiihrt werden konnte . 

10 • Bei MiSerfolg entsprechende Meldung mit einer moglichen 
Begriindung . 



Anpassungen der WAP Nachrichten 

15 

Nachfolgend werden mogliche Modif ikationen der WAP Nach- 
richten fur das Dienstmerkmal „Ruckruf n naher erlautert. 
Vorausgeschickt sei, dafi in den WAP Spezif ikationen der 
MMS User Agent dem MMS Client entspricht und anstatt des 

20 MMS Relay/Servers vom MMS Proxy/Relay die Rede ist, s. 
WAP-203-WSP, Version 4-May-2000 (s.o.) . Wenn vorliegend 
von MMS User Agent die Rede ist, soli damit auch der MMS 
Client umfaBt sein. Gleichso verhalt es sich mit den Beg- 
riffen MMS Relay/Server und MMS Proxy/Relay. Der Uber- 

25 sichtlichkeit halber werden im Folgenden nur die Begriffe 
MMS User Agent und MMS Relay/Server verwendet . 

Urn das Dienstmerkmal „ Ruckruf w in die WAP Implement ierung 
von MMS einzufiigen, wird erf indungsgemaS eine Modifikati- 
30 on der WAP Nachrichten M-Send.reg, M- Send, con f , M- 

Notification. ind, M-NotifyResp. ind und M-Dellvery. ind 
vorgeschlagen. In ihnen werden erf indungsgemaS verschie- 
dene Kopf-Felder (Header-Felder) erganzt bzw, modif i- 
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ziert. Nach WAP-203 -WSP (s.o.) besteht jedes Kopf-Feld 
aus einem kodierten Feld-Namen und einem kodierten Feld- 
Wert. Dabei existieren insgesamt vier Moglichkeiten den 
Feld-Wert zu kodieren, wobei das erste Oktett des Feld- 
5 Wertes uber die Art und Lange der Kodierung entscheidet 
(siehe Tabelle 1) . 

A.l. WAP Nachricht M-Send.req (von Sendeapplikation UAA 
zum Netzwerkelement RSA) 

10 

Der Absender einer MM A soil zum Ausdruck bringen, daS er 
seine MM A wieder zuruckrufen mochte . Dies geschieht durch 
das Versenden einer weiteren MM B an den gleichen Empf an- 
ger. Zu diesem Zwecke kann in der WAP Nachricht M- 

15 Send, req, mit der die MM B verschickt wird, ein Kopf-Feld 
erganzt werden, das die Identif ikationsnummer derjenigen 
MM tragt, die der Absender zuruckrufen mochte {ID1 von 
MM A aus Fig. 2) . Es wird vorgeschlagen, daS dieses Kopf- 
Feld den Namen X-Mms -Recall -ID und die hexadezimale Ko- 

20 dierung 0x7F (dezimal: 127) tragt. Message-IDs werden 
konform zum Encapsulation-Standard (WAP-209- 
MMSEncapsulation, Release 2000; Wireless Application Pro- 
tocol; WAP Multimedia Messaging Service; Message Encapsu- 
lation; MMS Proposed SCD 1.0) vorzugsweise als sog. Text- 

25 String kodiert. AuSerdem kann dem Absender einer MM mit 
Ruckruf -Auf trag bevorzugt die Moglichkeit gegeben werden, 
eine Riickmeldung anfordern zu konnen. Dazu wird vorge- 
schlagen, ein Kopf-Feld mit der zweckmafiigen Bezeichnung 
X-Mms -Request-Report und der hexadezimalen Kodierung 0x85 

30 (dezimal: 133) in die WAP Nachricht M-Send. req einzufuh- 
ren. Die Feld-Werte dieses Kopf-Feldes sind bevorzugt 
konform zum Encapsulation-Standard (s.o.) mit dem <Oc- 
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tetl2 8> fur „Ruckmeldung wird gewiinscht" und <Octetl29> 
fur „Ruckmeldung ist nicht erwunscht" kodiert* 

Des weiteren wird vorgeschlagen, fur den Fall eines be- 
5 dingten Riickrufs zusatzlich ein neues Kopf -Feld hinzuzu- 
fiigen, das diese Bedingungen fur das Ausfuhren des Riick- 
rufbefehls ubermittelt . Vorgeschlagen wird hierzu ein 
Kopf -Feld mit der beispielhaf ten Bezeichnung X-Mms- 
Recall-Cond, das vorzugsweise die hexadezimale Kodierung 

10 0x86 (dezimal: 134) tragt . Dieses Kopf -Feld wird vorzugs- 
weise mit dem <Octetl2 8> fur den Ruckruf nur vor Benach- 
richtigung ("Recall only before Notif ication") , mit dem 
<0ctetl2 9> fur Ruckruf nur vor dem Herunter laden, auch 
nach dem Versand einer Benachrichtigung ("Recall only be- 

15 fore Downloading") , mit dem <Octetl30> fur den Ruckruf im 
Falle des Nicht les ens der MM ("Recall only before Rea- 
ding") und mit dem <0ctetl31> fur Ruckruf unabhangig vom 
Bearbeitungsgrad der MM - auch nach dem Lesen - ("Recall 
even after Reading") kodiert. Bei der Einfuhrung weiterer 

20 Konditionen sind vorzugsweise entsprechende Feld-Werte 
hinzuzufiigen. Alternativ zur Einfuhrung des <Octetl31> 
kann auch vereinbart werden, daS ein Ruckruf -Befehl ohne 
Kopf -Feld X-Mms -Recall -Cond fur "Recall even after Rea- 
ding" steht. 

25 

A. 2 WAP Nachricht M-Send. conf (vom Netzwerkelement RSA 
zur Sendeapplikation UAA) 

Mit dieser WAP Nachricht kann der Sendeapplikation UAA 
30 gemaS der vorliegenden Erfindung zusatzlich mitgeteilt 
werden, ob der Dienstanbieter A den Ruckruf -Auft rag des 
Absenders (MMS User Agent A) angenommen hat . Dazu wird 
vorteilhaf terweise vorgeschlagen, ein neues Kopf -Feld mit 
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dem Mamen X-Mms- Supported- Feature und der hexadezimalen 
Kodierung 0x83 (dezimal: 131) in die WAP Nachricht M- 
Send. conf einzufxigen. Vorzugsweise werden als Feld-Werte 
konform zum Encapsulation- Standard (s.o.) das <Octetl28> 
5 fur eine Auf tragsbestatigung und das <Octetl3 0> fur eine 
negative Riickmeldung benutzt (vergleiche Fig. 10) . 

AuEerdem kann der Sendeapplikation UAA erf indungsgemafe 
zusatzlich mitgeteilt werden, ob der Dienstanbieter A das 

0 bedingte Ruckrufen unterstutzt. Dafiir wird hier vorge- 
schlagen, die Feld-Werte des X-Mms-Supported-Feature mit 
der hexadezimalen Kodierung 0x83 (dezimal: 131) bei- 
spielsweise mit dem Wert <Octetl31> zu erganzen. Dieser 
Wert steht hierbei fur die Unterstiitzung des bedingten 

5 Riickrufs. Falls die MM A noch auf dem Netzwerkelement RSA 
gespeichert ist und die Empf angsapplikation UAB noch 
nicht benachrichtigt wurde, wird die MM bevorzugt ge- 
loscht und die Sendeapplikation UAA wird bevorzugt uber 
diese Ausfuhrung informiert. Dafiir wird erf indungsgemaS 

0 vorgeschlagen, das Kopf-Feld X-Mms -Status zur WAP Nach- 
richt M-Send. conf hinzuzuf ugen . Dabei wird vorzugsweise 
der neue Feld-Wert <Octetl38> fur „Ruckruf erfolgreich, 
vor Benachrichtigung" definiert. Des weiteren wird hier 
vorgeschlagen, den neuen Feld-Wert <Octetl42> fur „Ruck- 

5 ruf f ehlgeschlagen, da Benachrichtigung gesendet wurde n 
festzulegen. Dieser kodierte Wert informiert die Sendeap- 
plikation UAA, die den Fall 1 des bedingten Riickrufs 
(Ruckruf nur vor der Benachrichtigung) ausgefuhrt haben 
wollte, daS das Loschen der MM A nicht erfolgen konnte, 

0 wenn die Benachrichtigung schon gesendet wurde . Dieser 
Fall kann auftreten, wenn die Sendeapplikation UAA und 
die Empf angsapplikation UAB demselben Netzwerkelement RS, 
hier also dem Netzwerkelement RSA, zugeordnet sind. 
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A. 3 WAP Nachricht M-Notifica.tion.ind (vom Netzwerkele- 
ment RSB zur Empf angsapplikation UAB) 

5 1st die Empfangsapplikation UAB bereits uber eine zum 

Download bereitliegende MM A informiert worden, kann gema£ 
der vorliegenden Erfindung in der WAP Nachricht M- 
Notification.ind ein neu definiertes Kopf-Feld mit der 
zweckmaSigen Bezeichnung X-Mms -Recalled - URI und der hexa- 

10 dezimalen Kodierung 0x80 (dezimal: 128) zum Einsatz kom- 
men. Mit seiner Hilfe kann der Empfangsapplikation UAB 
mitgeteilt werden, da£ die MM A mit dem angegebenen URI 
nicht mehr langer zum Herunterladen bereit liegt, weil 
sie der Absender wieder zuruckgeruf en hat. Der Feld-Wert 

15 dieses neu definierten Kopf-Feldes wird bevorzugt konform 
zum Encapsulation-Standard (s.o.) als Text-String ko- 
diert . 

Urn die Empfangsapplikation UAB liber den Zeitpunkt des Lo- 
20 schens informieren zu konnen, kann gemaS dieser Erfindung 
ein neu definiertes Kopf-Feld mit der zweckmaBigen Be- 
zeichnung X-Mms -Date -of -Execution und der hexadezimalen 
Kodierung 0x84 (dezimal: 132) erganzt werden. Die Feld- 
Wert e fur dieses Kopf-Feld werden bevorzugt nach dem En- 
25 capsulation-Standard (s.o.) als Long-Integer kodiert . 

In der URI der Benachrichtigung kann gemaS der vorliegen- 
den Erfindung auf den Speicherplatz einer Standard- Text - 
Nachricht (z. B.: „Diese MM wurde vom Absender wieder ge- 
30 loscht.") verwiesen werden, mit der das Netzwerkelement 
RSB auch eine Empfangsapplikation UAB uber einen ausge- 
fuhrten Ruckruf -Auf trag informieren kann, wenn dieses das 
Ruckruf -Di ens tmerkmal nicht unterstiitzt (also die neuen 
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Kopf-Felder nicht erkennt) unci versucht, eine MM von dem 
in der Benachrichtigung ausgewiesenen Speicherplatz her- 
unterzuladen. 

5 Falls die MM A/ die zuriickgeruf en werden soli, bereits an 
die Empf angsapplikation UAB ausgeliefert worden ist, kann 
erf indungsgemaS die WAP Nachricht M-Notification.lnd das 
in Abschnitt A.l definierte Kopf-Feld mit dem Namen X- 
Mms -Recall -ID beinhalten. Die Empf angsapplikation UAB 
10 kann daraufhin umgehend mit Hilfe der Message- ID (ID2 aus 
Fig. 2) das Loschen der MM A einleiten (vorausgesetzt es 
unterstiitzt das Riickruf -Dienstmerkmal) . 

Falls die zu loschende MM A von der Empf angsapplikation 

15 UAB heruntergeladen wurde, wird im Falle des bedingten 
Zuriickrufens die Empf angsapplikation UAB bevorzugt iiber 
die Konditionen zum Loschen der MM A inf ormiert . Hierfiir 
wird bevorzugt das erf indungsgemaS neu definierte Kopf- 
Feld X-Mms -Recall -Cond mit der hexadezimalen Kodierung 

20 0x86 (dezimal: 134) eingesetzt . In diesem Fall werden nur 
die kodierten Werte <Octetl3 0> fur den Riickruf im Falle 
des Nichtlesens der MM ("Riickruf vor dem Lesen") und <Oc- 
tetl31> fur den Riickruf unabhangig vom Bearbeitungsgrad 
der MM ( "Riickruf auch nach dem Lesen") benotigt. <0c- 

25 tet!2 8> fur Riickruf nur vor Benachrichtigung und <Oc- 

tetl29> fur Riickruf nur vor dem He runt er laden, auch nach 
dem Versand einer Benachrichtigung, werden hier nicht be- 
notigt, da in diesem Beispiel in beiden Fallen das Lo- 
schen der MM A vor dem Versand der Benachrichtigung erfol- 

30 gen sollte. 

A. 4 WAP Nachricht M-NotifyResp . reg {von Empf angsapplika- 
tion UAB zum Netzwerkelement RSB) 



WO 02/063839 



38 



PCT/EP02/00571 



Gemafi der vorliegenden Erfindung wird vorteilhaf terweise 
vorgeschlagen, in der WAP Nachricht M-NotifyResp.req op- 
tional ein neues Kopf -Feld einzufugen, mit dessen Hilfe 
5 dem Netzwerkelement RSB mitgeteilt werden kann, ob die 
Empf angsapplikation UAB die Meldung uber einen erfolg- 
reich ausgefuhrten Riickruf -Auf trag verstanden hat. Zu 
diesem Zweck wird vorzugsweise das aus anderen WAP Nach- 
richten bekannte Kopf -Feld X-Mms-Status benutzt und ein 
10 neuer Feld-Wert definiert: Es wird vorgeschlagen, daS das 
<Octetl3 6> die Bedeutung „Merkmal Riickruf unterstiitzt u 
hat . 

Falls die riickzuruf ende MM A bereits an die Empf angsappli- 
15 kation UAB ausgeliefert worden war, wird gemaS einer vor- 
teilhaften Variante der vorliegenden Erfindung vorge- 
schlagen, in der WAP Nachricht M~NotifyResp . reg das inr 
Encapsulation-Standard (s.o.) definierte Kopf-Feld X-Mms- 
Status einzufugen, mit welchem dem Netzwerkelement RS 
20 mitgeteilt werden kann, ob der Riickruf -Auf trag des Absen- 
ders erfolgreich auf der Empf angsapplikation UAB ausge- 
fiihrt werden konnte oder nicht. Dazu ist allerdings auch 
hier eine Erweiterung dieses Kopf-Feldes notwendig: Die 
Riickmeldung wird bevorzugt mit den beiden neuen Feld- 
25 Werten <Octetl32> fur „Riickruf -Auf trag wurde erfolgreich 
ausgefiihrt" und <Octetl3 3> fur „ Riickruf -Auf trag konnte 
nicht ausgefiihrt werden" realisiert. 

Fur den Fall des bedingten Riickrufs werden zusatzlich zu 
30 den Feld-Werten <Octetl32> fur „ Riickruf erfolgreich" und 
<Octetl3 3> fur „ Riickruf f ehlgeschlagen" , sowie zu den o~ 
ben vorgeschlagenen Feld-Werten <Octetl3 8> fiir „ Riickruf 
erfolgreich, vor Benachrichtigung u und <Octetl42> fur 
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„ Ruckruf f ehlgeschlagen, da Benachrichtigung gesendet 
wurde" (s. A. 2) folgende Feld-Werte vorgeschlagen: 

- <Octetl40> fur „Riickruf erfolgreich, bevor MM gelesen 
5 wurde w 

- <Octetl41> fiir „Riickruf erf olgreich, nachdem MM gele- 
sen wurde u 

- <Octetl44> fur „ Ruckruf f ehlgeschlagen, da MM gelesen 
wurde * 

10 - <Octetl45> fiir ,,Ruckruf f ehlgeschlagen, da MM 
geloscht wurde w . 

Dank dieser Mitteilungen kann-dann der Absender des Riick- 
ruf-Befehls iiber den genauen Ausgang seines Auftrages in- 
15 formiert werden. 

A. 5 WAP Nachricht M-Delivery . ind (vom Netzwerkelement 
RSA zur Sendeapplikation UAA) 

20 Weiterhin wird vorgeschlagen, vorzugsweise das in Ab- 

schnitt A. 4 erweiterte Kopf-Feld X-Mms-St&tus auch hier 
einzufugen. Mit seiner Hilfe kann dem Absender (Sendeap- 
plikation UAA) mitgeteilt werden, ob sein Riickruf -Auf trag 
erf olgreich ausgefuhrt werden konnte oder nicht, wenn 

25 auch hier die neuen Feld-Werte <0ctetl32> fiir „Riickruf- 
Auftrag wurde erf olgreich ausgefuhrt u und <Octetl33> fiir 
„ Ruckruf -Auf trag konnte nicht ausgefuhrt werden" benutzt 
werden (vergleiche Fig. 6) . AuSerdem kann der Absender 
iiber das Datum der Ausfiihrung seines Ruckruf -Auf trages 

30 mit Hilfe des in Abschnitt A. 3 definierten Kopf-Feldes 

mit der zweckmaSigen Bezeichnung X~Mms-Date-of -Execution 
informiert werden. 
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AuSerdem werden bevorzugt weitere neue Feld-Werte defi- 
niert : 

- <Octetl39> fur „Riickruf erfolgreich, vor dem Herun- 
5 terladen" 

- <Octetl43> fur „ Riickruf f ehlgeschlagen, da MM schon 
heruntergeladen wurde n 

Somit ermoglichen die verschiedenen Feld-Werte des Kopf- 
10 Feldes X-Mms -Status innerhalb der WAP Nachricht M- 

Delivery. ind eine Benachrichtigung des Absenders, ob und 
unter welchen Umstanden sein Riickruf -Auf trag ausgefiihrt 
wurde . 

15 Eine weitere Moglichkeit, den Absender eines bedingten 

Riickruf bef ehls uber die Ausfuhrung des Auft'rags zu infor- 
mieren, kann erf indungsgemaS durch die Definition eines 
neuen Kopf -Feldes realisiert werden, das bei den entspre- 
chenden WAP Nachrichten eingesetzt wird. Vorgeschlagen 

20 wird dazu ein Kopf-Feld mit dem beispielhaf ten Namen X- 
Mms -Recall -Status . Dieses Kopf-Feld kann in den oben be- 
schriebenen Fallen als Ersatz fiir das erweiterte Kopf- 
Feld X-Mms -Status dienen. Let z teres kann dann weiterhin 
in der in WAP-2 09-MMSEncapsulation, Release 2000 (s.o.) 

25 definierten Form eingesetzt werden. Das neue Kopf-Feld X- 
Mms -Recall -Status beinhaltet vorzugsweise nur Informatio- 
nen zur Ausfuhrung des Riickruf -Auf t rages . Fur den X-Mms- 
Recall- Status wird die hexadezimale Kodierung 0x88 (dezi- 
mal: 13 6) vorgeschlagen. Die moglichen Feld-Werte, welche 

30 die verschiedenen Ausf uhrungsszenarien abdecken, sind 
beispielsweise : 

- <Octetl2 8> fiir „ Riickruf erf olgreich" 
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~~ <Octetl29> fur „Ruckruf erf olgreich, vor Benachrich- 
tigung" 

- <Octetl3 0> fur „Ruckruf erf olgreich, vor dem Herun- 
terladen" 

5 - <Octetl31> fur „Ruckruf erf olgreich, bevor MM gelesen 

wurde * 

- <Octetl32> fur „Riickruf erfolgreich> nachdem MM gele- 
sen wurde xv 

- <Octetl33> fiir „Ruckruf f ehlgeschlagen" 

10 — <Octetl34> fur „Riickruf f ehlgeschlagen, da Ben- 

achrichtigung gesendet wurde" 

- <Octetl3 5> fiir „Riickruf f ehlgeschlagen, da MM herun- 
tergeladen wurde u 

- <Octetl36> fur „Ruckruf f ehlgeschlagen, da MM gelesen 
15 wurde w 

- <Octetl3 7> fur „Ruckruf f ehlgeschlagen, da Nachricht 
geloscht wurde u 

- <Octetl3 8> fur „Ruckruf f ehlgeschlagen, Nachricht 
nicht gefunden" 

20 - <Octetl39> fur „Riickruf f ehlgeschlagen , Nachricht 

weitergeleitet" . 

Bei weiteren Grunden oder Konditionen konnen die Feld- 
Werte und Kodierungen entsprechend erganzt werden. 

25 

B. DIENSTMERKMAL „ANDERN W 

Ein Benutzer des MMS, der eine Multimedia Message MM A ab- 
30 geschickt hat und diese bereits verschickte MM spater 

verandern mochte, kann gemaS dieser Erfindung eine neue 
MM B zusammen mit der Information verschicken, daS diese 
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MM B eine zuvor verschickte MM A andern, insbesondere er- 
setzen, soil. Unten stehende Ausfiihrungen gelten ganz 
allgemein fur Anderungen einer ersten Nachricht MM A/ so 
auch z.B. fur das nachtragliche Anhangen einer Datei an 
5 eine zuvor versendete MM A . 

Eine Anderung von MM A kann dadurch realisiert werden, da£ 
der Absender eine neue MM B verfaEt, die einen Anderungs- 
befehl beinhaltet, und diese an den gleichen Empf anger 

0 wie die zuvor verschickte MM A schickt . Zur Identifizie- 
rung der MM A wird vorteilhaf erweise die ID1 der zuvor 
verschickten und jetzt zu verandernden MM A benutzt . Die 
MM B mit der Anderungs - Information gelangt zunachst zum 
Netzwerkelement RSA. Hier wird iiberpruft, ob die MM A mit 

5 der ID1 noch im Zustandigkeitsbereich (MMSE A ) des Dienst- 
anbieters A ist, oder ob sie sich schon im MMSE B des 
Dienstanbieters B befindet. Beides ist moglich, je nach 
dem, ob vom Absender der MM A ein Zeitpunkt fur die frii- 
hestmogliche Auslieferung oder eine Giiltigkeitsdauer an- 

0 gegeben worden ist. Sobald die MM A in einem MMSE der be- 
teiligten MMS Dienstanbieter ausfindig gemacht worden 
ist, kann das Andern der MM A durch die MM B vom zustandi- 
gen Netzwerkelement RS eingeleitet werden. Praktisch rea- 
lisiert wird diese Aktion vorzugsweise durch das Loschen 

5 der alten MM A und das Weiterleiten der neuen MM B an den 
Empf anger. Der MMS Dienstanbieter hat gemaS dieser Erf in- 
dung die Moglichkeit, die Empf angsapplikation UAB liber 
einen gegebenenf alls ausgefuhrten Anderungs -Vorgang 
und/oder uber das Datum der Ausfuhrung des Anderungs - 

0 Vorgangs („diese MM wurde aktualisiert am, . . w ) in Kennt- 
nis zu setzen. 
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Hat der Empf anger (Empf angsapplikation UAB) der MM A noch 
keine Benachrichtigung uber die MM A erhalten, etwa weil 
die MM B mit dem Anderungsauf trag das Netzwerkelement RSB 
vor der zu andernden MM A erreicht, muS dieser auch nicht 
5 zwingend iiber eine vom Absender eingeleitete Anderungsak- 
tion informiert werden. Statt dessen kann das Netzwerk- 
element RSB warten, bis es die zu andernde MM A erhalt, 
und andert; insbesondere ersetzt, diese beim Eintreffen 
durch die MM B (vorausgesetzt , das MMS Netzwerkelement RSB 
10 unterstutzt das Riickruf -Dienstmerkmal ) . Der MMS Dienstan- 
bieter kann nach dieser Erf indung die Empf angsapplikation 
UAB bei der Zustellung der MM B davon in Kenntnis setzen, 
daS sie eine vom Absender nachtraglich geanderte MM ist 
und wann diese Anderung ausgefiihrt worden ist. 

15 

Falls die Empf angsapplikation UAB schon uber die fur ihn 
im MMSEb bereitliegende MM A mittels einer Benachrichti- 
gung (Notification) informiert worden ist und sich die 
MM A noch im Zustandigkeitsbereich des Dienstanbieters B 
20 befinden sollte, kann gerna£ dieser Erf indung die Emp- 

f angsapplikation UAB mit einer erneuten Benachrichtigung 
(Notification) davon in Kenntnis gesetzt werden, date der 
Absender seine MM A nachtraglich geandert hat und wann 
diese Anderung ausgefiihrt worden ist. 

25 

Sollte die MM A schon an den Empfanger ausgeliefert worden 
sein, so kann entweder die Empf angsapplikation UAB zu- 
nachst eine Benachrichtigung vom Dienstanbieter B erhal- 
ten, dafi eine MM B zum Ersatz der MM A vorliegt, oder die 
30 MM B mit dem Anderungsauf trag kann der Empf angsapplikation 
UAB unmittelbar zugestellt werden. Unabhangig davon, ob 
die MM B im PUSH-Modus oder im PULL-Modus zugestellt wor- 
den ist, kann das Andern, insbesondere das Ersetzen, der 
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MM A durch die MM B direkt in der Empf angsapplikation UAB 
stattfinden, sofern dies das Andern-Dienstmerkmal unter- 
stxitzt. Je nach Implementierung dieses Dienstmerkmals im 
Endgerat, den Einstellungen des Benutzers, den Einstel- 
5 lungen des Dienstanbieters und/oder des Netzbetreibers 
kann das Andern, insbesondere das Ersetzen, von MM A (und 
damit im Falle des PULL-Modus : zusatzlich das Anfordern 
■von MM B ) im Endgerat davon abhangig sein, ob die MM A be- 
reits vom Empf anger „angefaSt" (z.B. geoffnet, gelesen, 

10 weitergeleitet , etc.) worden ist. Sinnvoll erscheint, 

insbesondere solche MMs automatisch (d.h. ohne Riickfrage 
mit dem Empf anger) zu andern, welche noch nicht vom Emp- 
f anger „angefaSt w worden sind. Hat der Empf anger die MM A 
schon aus der Posteingangsbox genommen; weitergeleitet 

15 oder gelesen, so kann er zumindest noch dariiber infor- 
miert werden, daS der Absender mit MM B die zuvor ver- 
schickte MM A andern wollte. 

Der Absender/ Auf traggeber (Sendeapplikation UAA oder VAS- 
20 Applikation) kann gemaE einer vorteilhaf ten Variante der 
Erf indung iiber den Ausgang und das Datum der Ausfiihrung 
der von ihm eingeleiteten Anderungsaktion informiert wer- 
den, wenn die beteiligten MMS Dienstanbieter dies unter- 
stiitzen . 

25 

Die Identif ikation von MM A auf der Empf angsapplikation 
UAB kann insbesondere anhand einer Nachrichtenref erenz 
erfolgen, welche vorzugsweise ein URI 1st, unter dessen 
Speicherplatz eine Standard-Text -Nachricht des empf anger- 
30 seitigen Dienstanbieters B abgespeichert ist . Die URI 
setzt sich bevorzugt aus der Identif ikationsnummer ID1 
von MM A oder aus von einem empf angerseitigen Netzwerkele- 
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merit (inbesondere vom Netzwerkelement RSB) f estgelegten 
zweiten Identif ikationsnummer (ID2) zusammen. 

Um das gerade beschriebene Dienstmerkmal Andern, insbe- 
5 sondere Ersetzen, umsetzen zu konnen, wird gemafi der vor- 
liegenden Erfindung vorgeschlagen, daS eine oder mehrere 
der folgenden Inf ormationen zusatzlich zwischen den be- 
teiligten Instanzen (Sendeapplikation UAA, Netzwerkele- 
ment RSA, Netzwerkelement RSB und Empf angsapplikation 
10 UAB) ausgetauscht werden: 



Sendeapplikation UAA (MMS User Agent A) — > Netzwerkele- 
ment RSA (MMS Relay/Server A) (beim Versenden einer MM) : 

• Kennzeichnung, da£ es sich bei einer MM B um einen An- 
15 derungsbef ehl handelt. 

• Identif ikationsnummer der MM A/ die geandert werden 
soli . 

• Information, daS der Absender eine Ruckmeldung uber 
den Ausgang der von ihm eingeleiteten Ande rungs akti on 

20 anf order t. 



Netzwerkelement RSA (MMS Relay/Server A) — > Sendeapplika- 
tion UAA (MMS User Agent A) (bei der Bestatigung nach dem 
Versenden einer MM) : 

25 • Mitteilung des Dienstanbieters , ob dieser das Andern- 
Dienstmerkmal unterstiitzt . 

Netzwerkelement RSA (MMS Relay/Server A) -> Netzwerkele- 
ment RSB (MMS Relay/Server B) (nur dann notig, wenn Ab- 
30 sender und Empfanger zu unterschiedlichen MMSEs gehoren) : 
• Kennzeichnung, daS es sich bei einer MM B um einen An- 
derungsbef ehl handelt. 
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• I dent if ikationsnummer der MM A/ die geandert werden 
soil . 

• Information, dafi der Absender eine Ruckmeldung uber 
den Ausgang der von ihm eingeleiteten Anderungsaktion 

9 

5 anfordert 

Die Ubermittlung der Inf ormationen zwischen Netzwerkele- 
ment RSA und Netzwerkelement RSB ist davon abhangig, ob 
diese Inf ormationen beim Versenden der MM B vorhanden wa- 
ren. 

10 

Netzwerkelement RSB (MMS Relay/Server B) -> Empfangsap- 
plikation UAB (MMS User Agent B) (bei der Benachrichti- 
gung uber eine eingetrof fene MM) , vorzugsweise in einer 
Nacliricht : 

15 • Information, dag der Absender eine zum Download be- 

reitliegende MM A durch eine neue MM B geandert hat. Die 
Identif izierung beider MMs erfolgt anhand der Nach- 
richtenref erenzen (URIs) zu den betroffenen MMs. 

• Information, wann die zum Herunterladen bereitliegende 
20 MM A durch die neue MM B geandert wurde . 

oder : 

• Information, dag der Absender eine bereits zuvor aus- 
gelieferte MM A durch eine neue MM B andern, insbesondere 
ersetzen, mochte. Die Identif izierung der MM A , die ak- 

25 tualisiert wird, erfolgt anhand der individuellen Mes- 

sage ID und die Identif izierung der MM B , welche die MM A 
andern, insbesondere ersetzen, soil, erfolgt anhand 
der Nachrichtenref erenz (URI) . 

30 Empf angsapplikation UAB (MMS User Agent B) -> Netzwerk- 
element RSB (MMS Relay/Server B) (nach der Benachrichti- 
gung) : 
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• Information, ob der Empfanger uber den Anderungsauf - 
trag informiert werden konnte. 

Wurde im Fall des PULL-Modus der Empfanger von einer vor- 
5 liegenden MM B mit Anderungsauf trag unterrichtet, so kann 
er diese mittels der bekannten Mechanismen vom Netzwerk- 
element RSB beziehen. Im Fall des PUSH-Modus wird das 
Herunterladen der MM B vom MMS Dienstanbieter und nicht 
vom Empfanger initiiert. In diesem Fall konnen die beiden 
10 vorigen Schritte, Benachrichtigung und deren Bestatigung, 
entf alien. 

Netzwerkelement RSB (MMS Relay/Server B) -> Empfangsap- 
plikation UAB (MMS User Agent B) (bei der Zustellung ei- 
15 ner MM) : 

• Kennzeichnung, da£ die MM B einen Anderungsauf trag ent- 
halt, der auf der Empf angsapplikation UAB ausgefuhrt 
werden soil . 

• Information, welche bereits ausgelief erte MM A gean- 

20 dert, insbesondere ersetzt, werden soli. Die Identifi- 

zierung der MM A erfolgt anhand der individuellen nach- 
richtenidentif ikationsnummer (Message ID) . 
oder : 

• Information, daS die soeben ausgelief erte MM B eine 
25 nachtraglich geanderte MM ist. 

• Information, wann MM B vom Absender geandert worden 
ist. 

Empf angsapplikation UAB (MMS User Agent B) — > Netzwerk- 
30 element RSB (MMS Relay/Server B) (nach der Zustellung ei- 
ner MM) : 

• Information, ob der Anderungsauf trag erfolgreich aus- 
gefuhrt werden konnte . 
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• Information, ob der Anderungsauf trag automatisch 
durchgef lihrt wurde . 

• Information, ob der Empfanger liber den Anderungs-Vor- 
gang informiert wurde (und/oder der Anderung zuge- 

5 stimmt hat) . 

Netzwerkelement RSB (MMS Relay/Server B) Netzwerkele- 
ment RSA (MMS Relay/Server A) (nur dann notig, wenn Ab- 
sender und Empfanger zu unterschiedlichen MMSEs gehoren 
10 und wenn der Absender eine Ruckmeldung angefordert hat) : 

• Information, ob der Anderungsauf trag erfolgreich aus- 
gef lihrt werden konnte . 

• Information, wann der Anderungsauf trag ausgefuhrt wor 
den ist. 

15 • Information, ob der Anderungsauf trag automatisch 
durchgef uhrt wurde . 

• Information, ob der Empfanger uber die Anderung infor 
miert wurde (und/oder der Anderung zugestimmt hat) . 

• Information, ob eine bereits heruntergeladene MM A ge- 
20 andert, insbesondere ersetzt, wurde oder aber die MM A 

vor dem Andern noch nicht ausgeliefert worden war. 

• Identif ikationsnummer der MM A , die geandert, insbeson- 
dere ersetzt, wurde. 

25 Netzwerkelement RSA (MMS Relay/Server A) -> Sendeapplika 
tion UAA (MMS User Agent A) (beim Bericht) : 

• Information, ob der Anderungsauf trag erfolgreich aus- 
gefuhrt werden konnte . 

• Information, wann der Anderungsauf trag ausgefuhrt wor 
30 den ist . 

• Information, ob der Anderungsauf trag automatisch 
durchgef lihrt wurde. 
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• Information, ob der Empfanger liber die Anderung infor- 
miert wurde (und/oder der Anderung zugestimmt hat) . 

• Information, ob eine bereits heruntergeladene MM A ge- 
andert, insbesondere ersetzt, wurde oder aber die MM A 

5 vor der Anderung noch nicht ausgeliefert worden war. 

• Identif ikationsnummer der MM A , die geandert, insbeson- 
dere ersetzt, wurde. 

10 Zusatzliches Dienstmerkmal : Bedingtes Andern 

GemaS einer bevorzugten Ausf iihrungsf orm der Erf indung 
kann der Absender des Anderungsbef ehls Bedingungen zum 
Ausfuhren seines Wunsches angeben, Dabei legt die Sen- 
15 deapplikation UAA oder die VAS-Applikation fest, in wel- 
chem Fall die zuvor gesendete MM geandert wird. Das be- 
dingte Andern kann auch mit „ Conditional Replace * be- 
zeichnet werden. 

20 Der Dienstanbieter kann erf indung sgemaB das Verwenden de 
Dienstmerkmals „ Andern " auf die eigene oder bestimmte Do 
manen der Dienstanbieter begrenzen. Dies kann beispiels- 
weise anhand einer Identif izierung der Adresse des Emp- 
f angers (Rufnummer, Mailadresse oder weiteres) erfolgen. 

25 Eine weitere Moglichkeit ware das Einsetzen einer zusatz 
lichen Kennzeichnung (Flag) in dem Andern-Bef ehl . 

Bevorzugt basiert das bedingte Aktualisieren auf der Be- 
arbeitungsphase der zuvor gesendeten Nachricht (hier Mul 
30 timedia Message MM) . Der Absender entscheidet in diesem 
Fall, in welchem Zustand der MM diese geloscht werden 
soil. Mogliche Konditionen fur das Andern, insbesondere 
Ersetzen, sind: 
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1. Andern der MM nur, wenn diese auf dem Server liegt und 
der Empfanger davon noch nicht in Kenntnis gesetzt 
wurde. Das Andern erfolgt also nur, wenn noch keine 

5 Benachrichtigung (Notification) gesendet wurde. 

2. Andern der MM auch dann, wenn die Benachrichtigung 

(Notification) schon gesendet, aber die MM noch nicht 
herunterge laden wurde, 

10 

3. Andern der MM, wenn der Empfanger diese noch nicht ge- 
offnet bzw. gelesen hat. In diesem Fall kann das An- 
dern auch nach dem Herunterladen auftreten. 



15 4 . Andern der MM unabhangig vom Bearbeitungsgrad der MM 
beim Empfanger. Das Andern wird hier auch dann ver- 
sucht, wenn der Empfanger die MM gelesen hat. 



Bei der Realisierung dieses Dienstmerkmales wird vorteil 
20 hafterweise eine Standardkondition „ Default value" ange- 
nommen werden. Zum Bei spiel kann vereinbart werden, daS 
die Standardkondition einem der oben beschriebenen ' vier 
Falle entspricht. Diese Voreinstellung kann beispielswei 
se - solange nichts Genaues zum konditionellen Ausfuhren 
25 des Andern-Bef ehls geaufiert wurde - derart festgelegt 
werden, daE das Andern zum Bei spiel nur vor der Benach- 
richtigung erfolgen soil. Das System konnte auch so aus- 
gelegt sein, daS ein solches Andern nur vor dem Herunter 
laden der zu andernden MM oder sogar nach dem Offnen bzw 
30 Lesen erfolgen sollte. 

Im folgenden werden die Transaktionen zur Realisierung 
vom MM-Status-bedingten Dienstmerkmal „ Andern " behandelt 
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Eine bereits verschickte MM A kann also durch den Absender 
nachtraglich wieder zuriickgeruf en werden, indem er eine 
neue MM B verfaSt, die * einen bedingten Anderungsbef ehl und 
5 einen neuen, fur den Empf anger bestimmten Inhalt ( w Con- 
tent/Message Body") beinhaltet. Diese neue Nachricht wird 
dem gleichen Empf anger wie die zuvor verschickte MM A ge- 
sendet. Als Anderungskennung wird die Identif ikationsnum- 
mer (ID 1) der zuvor verschickten MM A benutzt (s.o) . Die 

10 MM B mit der Anderungsinf ormation gelangt zunachst zum 
Netzwerkelement RSA des Absenders . , Hier wird uberpriift, 
ob die MM A mit der ID 1 noch im Zustandigkeitsbereich des 
Dienstanbieters A (MMSE A ) ist, oder ob sie schon an das 
MMSE B des Dienstanbieters B weitergeleitet worden ist. 

15 Ers teres ist z.B. der Fall, wenn der vom Absender gewahl- 
te Zeitpunkt fur die gewunschte Zustellung seiner MM A 
noch nicht erreicht worden ist; letzteres ist z.B. der 
Fall, wenn die MM A noch nicht ihre Gultigkeitsdauer uber- 
schritten hat und noch nicht der Empf angsapplikation UAB 

20 zugestellt worden ist. 

Sobald die MM A in einem MMSE ausfindig gemacht wird, kann 
das Andern von MM A durch MM B vom zustandigen Netzwerkele- 
ment RS eingeleitet werden. Falls der ursprungliche Emp- 

25 fanger die an ihn adressierte MM an eine andere Adresse 
weitergeleitet hat, soli auch der Anderungsbef ehl vom 
Netzwerkelement RS entsprechend weitergeleitet werden. 
Wenn das Netzwerkelement RSB nur die Information hat, daS 
die MM weitergeleitet wurde, ohne das Ziel zu wissen 

30 {beispielsweise, wenn der ursprungliche Empf anger die an 
ihn adressierte MM an eine E-mail Adresse weitergeleitet 
hat) , kann der Absender des Anderungsbef ehl s iiber den Mi- 
Serfolg des Ruckrufs aufgrund des Weiterleitens infor- 



WO 02/063839 



52 



PCT/EP02/00571 



miert werden. Aus Vertraulichkeitsgrunden ware auch mog- 
lich, den MiEerfolg der Ausfiihrung zu melden, ohne in 
diesem Fall den Grund zu kommentieren . 

5 Ein besonders gunstiger Fall zum Ausfuhren des Anderungs- 
befehls liegt vor, wenn die MM noch auf dem Netzwerkele- 
ment RSA oder RSB liegt, und die Empf angsapplikation UAB 
noch nicht iiber diese Nachricht benachrichtigt wurde. Ein 
solcher Fall konnte zum Beispiel auftreten, wenn die MM 

10 auf Wunsch des Absenders ab einem bestimmten Zeitpunkt 
ausgeliefert werden sollte, der noch nicht eingetreten 
ist. Hier liegt die MM noch auf dem Netzwerkelement RSA 
des Absenders. Die MM kann auch auf dem Netzwerkelement 
RSB gespeichert sein, falls z.B. das Endgerat des Empf an - 

15 gers ausgeschaltet ist und die Gultigkeitsdauer der MM 
nicht uberschritten wurde. In diesen beiden Fallen kann 
das Andern der MM unabhangig der ausgewahlten Loschkondi- 
tionen erfolgen. Alle vier oben beschriebenen Anderungs- 
konditionen decken namlich diese Situation ab . 

20 

Falls die Empf angsapplikation UAB schon iiber die fur ihn 
im MMSE B bereitliegende MM A mittels einer Benachrichti- 
gung (Notification) informiert worden ist und sich die 
MM A noch im Zustandigkeitsbereich/Speicher des Dienstan- 

25 bieters B befinden sollte, kann erf indungsgemaS das An- 
dern nur in den oben mit 2, 3 und 4 numerierten Fallen 
erfolgen. Fur den Fall 1 des bedingten Anderns erhalt der 
Absender vorzugsweise eine Meldung, daS der Empf anger 
schon iiber die zuvor gesendete MM informiert wurde und 

30 die Anderung nicht vorgenommen werden konnte. Fur die 

weiteren Falle (2, 3 und 4) kann die Empf angsapplikation 
UAB mit einer erneuten Benachrichtigung (Notification) 
davon in Kenntnis gesetzt werden, daS die MM A durch die 
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MM B geandert wurde und somit nicht mehr zum Herunterladen 
bereit liegt. Statt dessen kann der Empf anger die neue 
MM B anfordern. 

5 Sollte die MM A schon an den Empfanger ausgeliefert worden 
sein, so kann das Andern nur fur den Fall 4 (Andern, un- 
abhangig vom Bearbeitungsgrad) und unter Umstanden fur 
den Fall 3 (Andern, nur wenn MM noch nicht geoff- 
net/gelesen wurde) erfolgen. Die Empf angsapplikation UAB 

10 wird - nur fur die Falle 3 und 4 - vorzugsweise mit einer 
neuen Benachrichtigung (Notification) davon in Kenntnis 
gesetzt, daS der Absender die MM A andern mochte . Diese 
Benachrichtigung beinhaltet bevorzugt die Konditionen des 
Anderns . Das Aktualisieren der MM A kann folglich direkt 

15 im MMS User Agent B statt finden, sofern dieses das 

Dienstmerkmal „Andern" unterstiitzt. Wenn es sich um den 
Fall 3 handelt, wird die MM bevorzugt nur dann geandert, 
wenn das Endgerat feststellt, daS die MM nicht geoffnet 
bzw. gelesen wurde. Fur den Fall 4 wird das Andern unab- 

20 hangig davon getriggert . Fur die Falle 1 (Andern vor der 
Benachrichtigung) und 2 (Andern nur vor dem Herunterla- 
den) kann das Andern nicht erfolgen. Der Absender erhalt 
bevorzugt eine Ruckmeldung mit der Information, daS die 
MM nicht geandert werden konnte, da eine Benachrichtigung 

25 schon verschickt wurde (Fall 1) oder well die MM schon 
heruntergeladen wurde (Fall 2) . 

Eine weitere Moglichkeit zur Realisierung des Andernvor- 
gangs ist erf indungsgemaS das Zustellen der MM B mit der 
30 Anderungsinf ormation bis zur Empf angsapplikation UAB. Das 
Andern wird dann im Endgerat des Empfangers durch die MM B 
und nicht durch die aus der MM B entstehende Benachrichti- 
gung (Notification) ausgelost . Dieser Fall wird im weite- 
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ren nicht detaillierter behandelt . 

Der Auftraggeber der Anderung (Sendeapplikation UAA oder 
VAS-Applikation) wird bevorzugt in alien beschriebenen 
5 Fallen liber den Ausgang und ggf . das Datum der Ausfxihrung 
der von ihm eingeleiteten Aktion informiert, insbesondere 
wenn er dies anfordert und wenn die beteiligten MMS 
Dienstanbieter dies ermoglichen. 

10 Da es sich beim bedingten Andern um eine MM handelt, wel- 
che die Empf angsapplikation UAB erreichen soli, behandeln 
MMSEs (Multimedia Messaging Service Environments) , die 
dieses Dienstmerkmal nicht unterstiitzen, die neue MM B 
vorzugsweise als einfache MM. Sie wird also der Empfangs- 

15 applikation UAB - ohne Ersetzung der MM A - als neue MM 
erreichen. Auch daruber wird der Absender vorzugsweise 
informiert . 

Um das gerade beschriebene Dienstmerkmal „Bedingtes An- 
20 dern u umsetzen zu konnen, wird erf indungsgemafi vorge- 

schlagen, daS eine oder mehrere der folgenden Information 
nen zusatzlich zwischen den beteiligten Instanzen (Sen- 
deapplikation UAA, Netzwerkelement RSA, Netzwerkelement 
RSB und Empf angsapplikation UAB) ausgetauscht werden. Als 
25 Basis dienen die aktuellen 3GPP Spezif ikationen 3G TS 140 
version 4.0.1 (s.o.) sowie 3G TS 23.140 version 4.0.0 
(s.o.) und WAP Spezif ikationen WAP-209~MMSEncapsulation; 
Release 2000 (s.o.), WAP-203 WSP (s.o.) und Report of the 
3 GPP TSG-T2 SWG3 (s.o.) . Im Folgenden wird naher auf die 
30 Unterschiede und Erganzungen im Vergleich zu dem unbe- 
dingten Andern eingegangen: 



Sendeapplikation UAA (MMS User Agent A) -» Netzwerkele- 
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merit RSA (MMS Relay/Server A) (beim Versencien einer MM) : 

• Bedingungen zum Ausfuhren des Anderns : 

- Andern nur vor Benachrichtigung . 

- Andern nur vor dem He runt er laden, auch nach dem Ver~ 
5 sand einer Benachrichtigung. 

- Andern nur, wenn die MM nicht geoffnet/ gelesen wur- 
de. 

- Andern unabhangig vom Bearbeitungsgrad der MM (auch 
nach dem Lesen der MM a) . 

10 

Netzwerkelement RSA (MMS Relay/Server A) — > Sendeapplika- 
tion UAA (MMS User Agent A) (bei der Bestatigung nach dem 
Versenden einer MM) : 

• Mitteilung des Dienstanbieters , ob dieser das bedingte 
15 Andern-Merkmal unterstiitzt . Hier konnte das System zwi- 

schen der Unterstutzung vom „ Andern w und „Bedingtes An- 
dern" unterscheiden . 

Netzwerkelement RSA (MMS Relay/Server A) — » Netzwerkele- 
20 ment RSB (MMS Relay/Server B) (nur dann notig, wenn Ab- 

sender und Empfanger zu unterschiedlichen MMSEs gehoren) : 

• Bedingungen zum Ausfiihren des Ersetzens: 

- Andern nur vor Benachrichtigung. 

- Andern nur vor dem Herunter laden, auch nach dem Ver- 
25 sand einer Benachrichtigung. 

- Andern nur, wenn die MM nicht gelesen wurde. 

- Andern unabhangig vom Bearbeitungsgrad der MM (auch 
nach dem Lesen) . 

30 Netzwerkelement RSB (MMS Relay/Server B) -> Empfangsap- 
plikation UAB (MMS User Agent B) (bei der Benachrichti- 
gung liber der eingetrof f enen MM B ) : 
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• Bedingungen zum Ausfuhren des Anderns : 

- Andern nur vor dem Herunterladen, auch nach dem Ver- 
sand einer Benachrichtigung. Diese Bedingung wird nur 
dann mitgeteilt, wenn die MM nicht heruntergeladen 

5 wurde . 

- Andern nur, wenn die MM nicht gelesen wurde. 

- Andern unabhangig vom Bearbeitungsgrad der MM (auch 
nach dem Lesen) . 



10 Empf angsapplikation UAB (MMS User Agent B) Netzwerk- 
element RSB (MMS Relay/Server B) (nach der Benachrichti- 
gung) : 

• Information, ob der bedingte Andern-Auf trag erfolgreich 
ausgefuhrt werden konnte . 

15 • Bei MiSerfolg entsprechende Meldung mit einer moglichen 
Begrundung . 

Netzwerkelement RSB (MMS Relay/Server B) -> Netzwerkele- 
ment RSA (MMS Relay/Server A) (nur dann notig, wenn Ab~ 
20 sender und Empfanger zu unterschiedlichen MMSEs gehoren 
und wenn der Absender eine Ruckmeldung angefordert hat) : 

• Information, ob der bedingte Andern -Auft rag erfolgreich 
ausgefuhrt werden konnte. 

• Bei MiSerfolg entsprechende Meldung mit einer moglichen 
Begriindung . 



Netzwerkelement RSA (MMS Relay/Server A) -» Sendeapplika- 
tion UAA (MMS User Agent A) (beim Bericht) : 

• Information, ob der bedingte Andern-Auf trag erfolgreich 
ausgefuhrt werden konnte. 

• Bei MiSerfolg entsprechende Meldung mit einer moglichen 
Begriindung . 
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Aixpassungen der WAP Nachrichten 

5 Nachfolgend werden mogliche Modif ikationen der WAP Nach- 
richten fur das Andern-Dienstmerkmal naher erlautert . Die 
Anpassungen und Zuweisungen sind beispielhaft und konnen 
durchaus variiert werden: Um das Andern-Dienstmerkmal in 
. die WAP Implement ierung von MMS einzufuhren, wird gemaiS 

0 der vorliegenden Erfindung eine Modifikation der WAP 

Nachrichten M-Send.req, M-Send.conf , M-Notification. ind, 
M-NotifyResp. req, M-Retrieve . conf , M-Acknowledge . ind und 
M-Delivery. ind vorgeschlagen. In ihnen werden vorteil- 
hafterweise analog zum Vorgehen in Abschnitt A (Dienst- 

5 merkmal Riickruf) verschiedene Kopf-Felder erganzt bzw. 
modif iziert. Im folgenden wird wieder von MMS User Agent 
bzw. MMS Proxy/Server gesprochen, womit auch MMS Client 
bzw. MMS Proxy/Relay gemeint ist. 

0 B.l WAP Nachricht M-Send. req (von Sendeapplikation UAA 
zum Netzwerkelement RSA) 

Der Absender einer MM soli zum Ausdruck bringen konnen, 
da£ er nachtraglich seine bereits verschickte MM A durch 

5 eine neue MM B andern, insbesondere ersetzen, mochte . Be- 
vorzugt wird zu diesem Zweck in der WAP Nachricht Af- . 
Send.reg, mit der die neue MM B verschickt wird, ein wei- 
teres Kopf-Feld erganzt, das die Identif ikationsnummer 
derjenigen MM tragt, die durch MM B geandert, insbesondere 

0 ersetzt, werden soli (namlich ID1 von MM A aus Fig. 2) . Es 
wird vorgeschlagen, da£ dieses Kopf-Feld den Namen X-Mms- 
Repla.ce-ID und die hexadezimale Kodierung 0x81 (dezimal: 
129) tragt. Message-IDs werden konform zum Encapsulation- 
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Standard (s.o.) vorzugsweise als Text-String kodiert. Au- 
Berdem wird dem Absender einer MM mit Anderungsauf trag 
vorzugsweise die Moglichkeit gegeben, eine Ruckmeldung 
anzufordern. Dazu wird vorgeschlagen, das in Abschnitt 

5 A.l definierte Kopf-Feld mit der zweckmaSigen Bezeichnung 
X~Mms -Request-Report mit der hexadezimalen Kodierung 0x8 5 
(dezimal; 133) in die WAP Nachricht M-Send.req einzufiih- 
ren. Die Feld-Werte dieses Kopf-Feldes werden vorteil- 
hafterweise konform zum Encapsulation- Standard (s . o . ) mit 

0 dem <Octetl2 8> fiir „ Ruckmeldung wird gewunscht" und <Oc- 
tetl29> fur ^Ruckmeldung ist nicht erwunscht" kodiert. 

Weiterhin wird vorgeschlagen, zusatzlich ein neues Kopf- 
Feld hinzuzufugen, das Bedingungen des Ausfuhrens des An- 

5 derungsbef ehls ubermittelt. Vorgeschlagen wird hierzu ein 
Kopf-Feld mit der beispielhaf ten Bezeichnung X-Mms- 
Replsice-Cond, das vorzugsweise die hexadezimale Kodierung 
0x87 (dezimal: 135) auf weist . Dieses Kopf-Feld wird vor- 
zugsweise mit dem <Octetl28> fur das Ersetzen nur vor Be- 

3 nachrichtigung ( "Replace only before Notification") , mit 
dem <Octetl29> fur das Ersetzen nur vor dem Herunterla- 
den, auch nach dem Versand einer Benachrichtigung 
("Replace only before Downloading"), mit dem <Octetl30> 
fur das Ersetzen im Falle des Nichtlesens ("Replace only 

5 before Reading") und mit <0ctetl31> fur das Ersetzen un- 
abhangig vom Bearbeitungsgrad der MM - auch nach dem Le- 
sen - ("Replace even after Reading") kodiert. Bei der 
Einfuhrung weiterer Konditionen sind vorzugsweise ent- 
sprechende Feld-Werte hinzuzufugen. 

3 

B.2 WAP Nachricht M-Send.conf (vom Netzwerkelement RSA 
zur Sendeapplikation UAA) 
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Mit dieser WAP Nachricht kann der Sendeapplikation UAA 
gemaS der vorliegenden Erfindung mitgeteilt werden, ob 
der Dienstanbieter A dem Ande rung sauft rag des Absenders 
(Sendeapplikation UAA) entsprechend gehandelt hat bzw. 
5 handeln konnte. Dazu wird vorgeschlagen, das in Abschnitt 
A. 2 zum Zwecke des Ruckruf -Dienstmerkmals eingefuhrte 
Kopf-Feld mit der zweckmaEigen Bezeichnung X-Mms- 
Supported -Feature vorzugsweise auch hier zu nutzen. Als 
Feld-Werte kommen dann entweder das <Octetl29> fiir „An- 
.10 dem-Merkmal unterstiitzt n oder das <Octetl3 0 > fiir „keine 
Unterstutzung tt zum Einsatz. 

Des weiteren wird fiir den Fall des bedingten Anderns vor- 
geschlagen, die Feld-Werte des X-Mms- Supported- Feature 

15 beispielsweise mit der hexddezimalen Kodierung 0x83 (de- 
zimal : 131) mit dem Wert <Octetl32> zu erganzen. Dieser 
Wert steht fur die Unterstutzung des bedingten Anderns 
bzw. Ersetzens, Falls die MM A noch auf dem Netzwerkele- 
ment RSA gespeichert ist, und die Empf angsapplikation UAB 

20 noch nicht benachrichtigt wurde, wird die MM geandert und 
Sendeapplikation UAA wird vorzugsweise uber diese Ausfuh- 
rung informiert. Dafur wird erf indungsgemaK vorgeschla- 
gen, das Kopf-Feld X-Mms -Status zur WAP Nachricht M- 
Send. conf hinzuzuf ligen. Dabei wird vorzugsweise der neue 

25 Feld-Wert <Octetl48> fiir „Andern erfolgreich, vor Benach- 
richtigung" definiert. Des weiteren wird hier vorgeschla- 
gen, den neuen Feld-Wert <Octetl52> fiir „Andern fehlge- 
schlagen, da Benachrichtigung gesendet wurde" festzule- 
gen. Dieser kodierte Wert informiert die Sendeapplikation 

30 UAA, die den Fall 1 des bedingten Ersetzens (Andern nur 
vor der Benachrichtigung) ausgefuhrt haben wollte, dalS 
die Aktualisierung der MM A nicht erfolgen konnte, da die 
Benachrichtigung schon gesendet wurde. Dieser Fall kann 
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auftreten, wenn Sendeapplikation UAA und Empf angsapplika 
tion UAB dem selben Net zwerke lenient RS, also Netzwerkele 
merit RSA, zugeordnet sind. Des weiteren werden vorzugs- 
weise weitere neue Feld-Werte def iniert : 
<Octetl49> fur w Andern erfolgreich, vor dem Herunter- 
laden", und 

<Octetl53> fiir /; Andern f ehlgeschlagen, da MM herunterge- 
laden wurde". 

Der letztere Fall kann auftreten, wenn der Absender den 
Fall 2 des bedingten Anderns (Andern vor dem Herunterla- 
den) verlangt hat. 

B.3 WAP Nachricht M-Notifica.tion.ind (vom Netzwerkele- 
ment RSB zur Empf angsapplikat ion UAB) 

Nach dieser Erfindung wird in der WAP Nachricht M- 
Notification.ind vorzugsweise ein neu definiertes Kopf- 
Feld mit der zweckmaSigen Bezeichnung X~Mms-Replaced-URI 
und der hexadezimalen Kodierung 0x82 (dezimal: 130) er- 
ganzt . Mit seiner Hilfe kann der Empf angsapplikation UAB 
nach einer bereits erfolgten Benachrichtigung mitgeteilt 
werden, daS die MM A unter dem angegebenen URI nicht mehr 
langer zum Herunterladen bereit liegt, weil sie der Ab- 
sender durch eine neu MM B mit einem anderen URI ersetzt 
hat. Der Feld-Wert dieses neu definierten Kopf-Feldes 
wird vorteilhaf terweise konform zum Encapsulation- 
Standard (s.o.) als Text -String kodiert . Urn die Empfangs 
applikation UAB iiber den Zeitpunkt der Aktualisierung in 
formieren zu konnen, wird gemaJS einer vorteilhaf ten Vari 
ante der Erfindung das in Abschnitt A. 3 neu definierte 
Kopf-Feld mit der zweckmaSigen Bezeichnung X-Mms-Date-of 
Execution erganzt . 
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Wenn sich die zu andernde, insbesondere zu ersetzende, 
MM A schon auf der Empf angsapplikation UAB befindet, wird 
vorteilhaf terweise in der WAP Nachricht M- 
Notification. ind das in Abschnitt B.l neu definierte 
5 Kopf-Feld mit der zweckmafeigen Bezeichnung X-Mms -Replace - 
ID und der hexadezimalen Kodierung 0x81 (dezimal: 129) 
erganzt . Die Empf angsapplikation UAB erkennt daran, da£ 
die zum Herunterladen bereitliegende MM B einen Anderungs- 
befehl fiir die MM A mit der entsprechenden Nachrichten- 
10 identif ikationsnummer beinhaltet . Das Herunterladen der 
MM B kann daraufhin je nach den Einstellungen des Benut- 
zers, den Einstellungen des MMS Dienstanbieters und/oder 
des Netzbetreibers entweder im PUSH-Modus oder im PULL- 
Modus eingeleitet werden. 

15 

Wie erwahnt , informiert die WAP Nachricht M- 
Notification.ind die Empf angsapplikation UAB iiber das 
Eintreffen der Nachricht MM B , die MM A andern, insbeson- 
der ersetzen, soil. Fur das bedingte Andern muS die Emp- 

20 f angsapplikation UAB iiber die Konditionen des Anderns in- 
formiert werden. Hierfiir wird vorzugsweise das neu defi- 
nierte Kopf -Feld X-Mms -Replace -Cond mit der hexadezimalen 
Kodierung 0x87 (dezimal: 135) eingesetzt. In diesem Fall 
werden nur die kodierten Werte <Octetl30> fur das Andern, 

25 nur wenn die MM nicht gelesen wurde, und <Octetl31> fur 
das Andern unabhangig vom Bearbeitungsgrad der MM (auch 
nach dem Lesen) benotigt . <Octetl28> fiir das Andern nur 
vor Benachrichtigung und <Octetl2 9> fiir das Andern nur 
vor dem Herunterladen - auch nach dem Versand einer Be~ 

30 nachricht igung - werden hier nicht benotigt, da in beiden 
Fallen das Andern der MM vor dem Versand der Benachrich- 
tigung erfolgen sollte. Falls die Bedingungen zum Andern 
der MM A erfiillt sind, kann diese MM schon geloscht wer- 
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den, auch bevor MM B in der Empf angsapplikation UAB an- 
kommt . 

B.4 WAP Nachricht M-NotifyResp.ind (von Empf angsapplika- 
5 tion UAB zum Netzwerkelement RSB) 

Erf indungsgemaE wird vorgeschlagen, in der WAP Nachricht 
M-NotifyResp. ind das im Encapsulation- Standard (s.o.) de- 
finierte Kopf-Feld X-Mms-Status einzufugen. Damit dem 

10 Netzwerkelement RS mitgeteilt werden kann, ob der Ande- 

rungsauftrag des Absenders im PUSH-Modus erfolgreich aus- 
gefuhrt werden konnte oder nicht, ist auch hier eine Er- 
weiterung dieses Kopf-Feldes (analog zu dem Vorgehen in 
Abschnitt A, Dienstmerkmal Ruckruf) notwendig : Die Ruck- 

15 meldung wird in dieser Erfindung vorzugsweise mit den 

beiden neuen Feld-Werten <0ctetl34> fur „Anderungsauf trag 
wurde erfolgreich ausgefiihrt" und <Octetl3 5> fur „Ande- 
rungsauftrag konnte nicht ausgefiihrt werden" reali'siert. 

20 Zusatzlich zu den zuvor vorgeschlagenen Feld-Werten <0c- 
tetl34> und <0ctetl35> sowie dem oben vorgeschlagenen 
Feld-Wert <Octetl48> fur „Andern erfolgreich, vor Benach- 
richtigung" und <Octetl52> fur „Andern f ehlgeschlagen, da 
Benachrichtigung gesendet wurde" werden folgende Feld- 

25 Werte vorgeschlagen : 

- <Octetl5 0> fur „Andern erfolgreich, bevor MM gelesen 
wurde w 

- <Octetl51> fur „Andern erfolgreich, nachdem MM gele- 
30 sen wurde" 

- <Octetl54> fur „Andern f ehlgeschlagen, da MM gelesen 
wurde w 

- <Octetl55> fiir „Replace f ehlgeschlagen, da MM 
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geloscht wurde". 

Dank dieser Mitteilungen kann dann der Absender des Ande- 
rungsbef ehls iiber den" genauen Ausgang seines Auftrages 
5 inforrniert werden. 

B.5 WAP Nachricht M-Retrieve . conf (vom Netzwerkelement 
RSB zur Empf angsapplikation UAB) 

10 Wenn die zu andernde MM A schon im MMSE B durch MM B geandert 
werden konnte, bietet sich gemaS der vorliegenden Erfin- 
dung an, in der WAP Nachricht M~Retrieve. conf , mit der 
MM B an die Empf angsapplikation UAB ubermittelt wird, vor- 
zugsweise das im Encapsulation-Standard (s.o.) definierte 

15 erweiterte Kopf-Feld X-Mms- Status mit dem Feld-Wert <Oc- 
tetl34> fur „ Andern erfolgreich" und das in Abschnitt A , 3 
neu definierte Kopf-Feld mit der zweckmafiigen Bezeichnung 
X-Mms -Date-of -Execution einzufugen. Dadurch kann das 
Netzwerkelement RSB der Empf angsapplikation UAB signal i- 

20 sieren, daJS die MM B eine nachtraglich geanderte MM ist 

und wann der Ande rungs auft rag des Absenders im Zustandig- 
keitsbereich des MMSE B ausgefuhrt worden ist. 

Wenn sich die zu andernde MM A schon auf der Empfangsap- 
25 plikation UAB befindet, ist es gemaS der vorliegenden Er- 
findung vorteilhaft, in der WAP Nachricht M-Retrieve . conf 
ebenfalls das in Abschnitt B.l definierte Kopf-Feld mit 
dem Namen X-Mms -Replace- ID zu erganzen. Mit ihm kann das 
Andern der MM A auf der Empf angsapplikation UAB mit Hilfe 
30 der Message-ID eingeleitet werden (s. Fig. 2) 7 falls die 
Empfangsapplikation UAB das Andern -Di ens tmerkmal unter- 
stutzt. Andernfalls wird dem Empf anger dadurch nur ange- 
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zeigt, da£ der Absender die MM A durch die neue MM B andern 
wollte . 

Im Falle des bedingten Anderns wird yorgeschlagen, das 
5 oben neu definierte Kopf-Feld X-Mms -Replace -Cond vorteil- 
hafterweise dieser Nachricht zuzufiigen. Dabei konnen die 
Feld-Werte <Octetl30> fur w Ersetzen nur, wenn die MM 
nicht gelesen wurde u und <Octetl31> fur „Ersetzen unab- 
hangig vom Bearbeitungsgrad der MM n , d.h. auch nach dem 
10 Lesen, verwendet werden. Damit wird die Empf angsapplika- 
tion UAB informiert, in welchem Fall die alte MM ersetzen 
werden soil . 

B.6 WAP Nachricht Acknowledge . ind (von Empf angsappli- 
15 kation UAB zum Netzwerkelement RSB) 

Gemafi dieser Erfindung wird in einer vorteilhaf ten Wei- 
terbildung vorgeschlagen, in der WAP Nachricht M- 
Acknowledgement . ind das im Encapsulation-Standard (s.o.) 

20 definierte Kopf-Feld X-Mms -Status einzufiigen. Damit dem 
Netzwerkelement RS mitgeteilt werden kann, ob der Ande- 
rungsauftrag des Absenders im PULL-Modus erfolgreich aus- 
gefiihrt werden konnte oder nicht, ist auch hier eine Er- 
weiterung dieses Kopf-Feldes (analog zu dem Vorgehen in 

25 Abschnitt A, Dienstmerkmal Ruckruf) notwendig : Die Ruck- 
meldung wird in dieser Erfindung vorteilhaf terweise mit 
den beiden neuen Feld-Werten <Octetl34> fur w Ande rungs- 
auftrag wurde erfolgreich ausgefiihrt" und <Octetl35> fur 
„Anderungsauf trag konnte nicht ausgefuhrt werden w reali- 

30 siert. 

Des weiteren konnen die Feld-Werte <Octetl49>, <Oc- 
tetl50> / <Octetl51> / <Octetl53>, <Octetl54> und <0c- 
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tetl55> verwendet werden (s.o.). 

B.7 WAP Nachricht M-Delivery. ind (von Netzwerkelement 
RSA zur Sendeapplikation UAA) 

5 

Weiterhin wird vorgeschlagen, das in den Abschnitten B.4 
bzw. B.6 erweiterte Kopf-Feld X~Mms- Status auch hier ein- 
zufugen. Mit seiner Hilfe kann dem Absender (Sendeap- 
plikation UAA) mitgeteilt werden, ob sein Anderungsauf - 

10 trag erfolgreich ausgefiihrt werden konnte oder nicht, 
wenn auch hier die oben genannten neuen Feld-Werte be- 
nutzt werden, wobei ein Teil oder alle oben beschriebenen 
Werte auftreten konnen. AuSerdem wird der Absender vor- 
teilhaf terweise uber das Datum der Ausfuhrung seines An- 

15 derungsauft rages mit Hilfe des in Abschnitt A. 3 definier- 
ten Kopf-Feldes mit der zweckmaSigen Bezeichnung X-Mms~ 
Date- of -Execution inf ormiert . 

Eine weitere Moglichkeit, den Absender eines bedingten 
20 Anderungs-Bef ehls iiber die Ausfuhrung des Anderungsauf - 
trags zu informieren, kann erf indungsgemaS durch die De- 
finition eines neuen Kopf-Feldes realisiert werden, das 
. bei den entsprechenden WAP Nachrichten eingesetzt wird. 
Vorgeschlagen wird dazu ein Kopf-Feld mit dem beispiel- 
25 haften Namen X-Mms-Replace-Status . Dieses Kopf-Feld kann 
in den oben beschriebenen Fallen als Ersatz fur das er- 
weiterte Kopf-Feld X-Mms-Status dienen. Letzteres kann 
weiter in der in WAP-209-MMSEncapsulation, Release 2000 
(s.o.) definierten Form eingesetzt werden. Das neue Kopf- 
30 Feld beinhaltet vorzugsweise nur Inf ormationen zur Aus- 
fuhrung des Andern-Auf trages . Fur den X-Mms~Replace- 
Status wird die hexadezimalen Kodierung 0x89 (dezimal: 
13 7)- vorgeschlagen. Die moglichen Feld-Werte, welche die 
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verschiedenen Ausfuhrungsszenarien abdecken, sind bei- 
spielsweise : 



- <Octetl28> fur „Andern erfolgreich" 

5 - <Octetl29> fur „Andern erfolgreich, vor Benachrich- 

tigung" 

- <Octetl3 0> fur „Andern erfolgreich, vor dem Herunter- 
laden" 

- <Octetl31> fur ;/ Andern erfolgreich, bevor MM gelesen 
10 wurde u 

- <Octetl32> fur ;/ Andern erfolgreich, nachdem MM gele- 
sen wurde u 

- <Octetl33> fur „Andern f ehlgeschlagen" 

- <Octetl34> fur „Andern f ehlgeschlagen, da Benachrich- 
15 tigung gesendet wurde" 

- <Octetl35> fur „Andern f ehlgeschlagen, da MM herun- 
tergeladen wurde" 

- <Octetl3 6> fur „Andern f ehlgeschlagen, da MM gelesen 
wurde n 

20 - <Octetl37> fur „Andern f ehlgeschlagen, da Nachricht 

geloscht wurde " 

- <Octetl38> fur „Andern f ehlgeschlagen, Nachricht 
nicht gefunden" 

- <Octetl39> fur „Andern f ehlgeschlagen, Nachricht 
25 weitergeleitet" . 

Bei weiteren Grunden oder Konditionen konnen die Feld- 
Werte und Kodierungen entsprechend erganzt werden. 

30 Eine weitere Alternative zum X-Mms -Replace -Status zusam- 
men mit dem oben eingefiihrten Kopf-Feld X-Mms -Replace- 
Status ware erf indungsgemaE ein neues Kopf-Feld, das fur 
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die Riickmeldung zur Ausfiihrung des Anderungs- und des 
Riickrufbef ehls eingesetzt werden kann. Vorgeschlagen wird 
hierfiir ein Kopf-Feld mit dem beispielhaf ten Namen X~Mms- 
Opera.tion-Sta.tus* Dieses Kopf-Feld kann die hexadezimale 
5 Kodierung 0x90 (dezimal: 138) haben, zusammen mit folgen- 
den Feld-Werten: 

- <Octetl2 8> fur „ Ausfiihrung erfolgreich" 

- <Octetl29> fur ,,Ausf iihrung erfolgreich, vor Ben- 
10 achr i cht igung * 

- <Octetl3 0> fur „ Ausfiihrung erfolgreich, vor dem 
Herunterladen" 

- <Octetl31> fur ^Ausfiihrung erfolgreich, bevor MM ge- 
lesen wurde" 

15 - <Octetl32> fur „Ausfiihrung erfolgreich, nachdem MM 

gelesen wurde" 

- <Octetl33> fur ,,Ausf iihrung f ehlgeschlagen" 

- <Octetl34> fur ,,Ausf iihrung f ehlgeschlagen, da Ben- 
achricht igung gesendet wurde" 

20 - <Octetl35> fiir „Ausfiihrung f ehlgeschlagen, da MM 

heruntergeladen wurde" 

- <Octetl36> fiir ^Ausfiihrung f ehlgeschlagen, da MM ge- 
lesen wurde" 

- <Octetl3 7> fiir „ Ausfiihrung f ehlgeschlagen, da 
25 Nachricht geloscht wurde" 

- <Octetl3 8> fiir „ Ausfiihrung f ehlgeschlagen, Nachricht 
nicht gefunden" 

- <Octetl3 9> fiir „ Ausfiihrung f ehlgeschlagen, Nachricht 
weitergeleitet" . 



30 



Fig- 5 zeigt noch einmal sieben, vorteilhaf terweise neu 
eingefiihrte Kopf-Felder einschlieKlich der Kodierungen 
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von Feld-Name und Feld-Wert . In Pig. 6 ist das urn neue 
Feld-Werte erweiterte Kopf-Feld X-Mms- Status dargestellt. 
In den Fig. 7 und 8 sind die Kopf-Felder der alternativen 
Real isierungsmoglichkei ten (Ausf uhrungsbeispiele 3 und 4, 
5 s.u.) dargestellt. Die entsprechenden Erganzungen in den 
Kopf-Feldern der entsprechenden WAP Nachrichten sind in 
den Tabellen 2 bis 8 am Ende der Beschreibung aufgelis- 
tet. Es ist durchaus moglich, daS auch nur einzelne Er- 
ganzungen in diesen Kopf-Feldern vorgenommen werden. 

10 

Fur den Fall der bedingten Manipulation zeigt Fig. 9 die 
neu eingefiihrten Kopf-Felder Mms -Recall -Cond, X-Mms- 
Replace -Cond, X-Mms -Recall -Status , X-Mms -Replace -Status 
und X-Mms -Operation-Status einschlieElich der Kodierungen 
15 von Feld-Name und Feld-Wert. In Fig. 10 ist das urn neue 
Feld-Werte erweiterte Kopf-Feld X-Mms -Supported- Feature 
dargestellt. Das in Fig. 6 dargestellte Kopf-Feld X-Mms- 
Status enthalt ebenfalls auf die bedingte Manipulation 
bezogene neue Feld-Werte. 

20 

C. BINARE KODIERUNG 

C.l Ohne Bedingung fur Riickruf bzw. Andern 

25 

In den folgenden Ausf uhrungsbeispielen wird detailliert 
auf die in den WAP Nachrichten benutzten Kopf-Felder ein- 
gegangen, ohne da£ zunachst Bedingungen fur den Riickruf 
bzw. das Andern einer ersten Nachricht vorgesehen sind. 
30 Dabei wird beispielhaft folgendes Szenario angenommen: 
Sendeapplikation UAA verschickt eine MM A bestehend aus 
einem Text und einem JPEG-Bild an einen Empfanger und 
will diese spater zuruckrufen (Beispiel 1) bzw. durch ei- 
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ne neue MM B ersetzen (Beispiel 2) . 

M-Send.req (Sendeapplikation UAA -> Netzwerkelement RSA) 



5 X-Mms -Message-Type : m-send-req 

X-Mms - Transa ction-ID: 10 
X-Mms - Versi on: 1 . 0 

Date: Thu, 26 Oct 2000 12:12:19 +0200 
From : abc@si em ens . de 
10 To: xyz@si emens . de 

Subject: multimedia message a 

Con tent- Type : mul tipart/ related; boundary^ " - 
_=_NextPart_ 000__ ff 

15 __=_NextPart_000__ 

Content - Type : text/plain; name= "meeting . txt w 
Con tent- Transfer-Encoding : quoted -prin tabl e 

Hallo xyz , 
20 hier ist die gewixnschte Agenda 

fur unser nachstes Meeting. 
GruB, abc 

___ =__Nex tPart_ 000_ 

25 Content-Type: image/ jpeg ; name- " agenda . jpg" 

Con ten t - Transfer-Encoding : base64 
Content-ID: <1725782> 

30 = Next Part 000 



Die Sendeapplikation UAA des Benutzers mit der Adresse 
ajbc@sieinens.de verschickt eine MM A bestehend aus einem 
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Text (MIME content type „ text /plain") und einem JPEG-Bild 
(MIME content type „ image/ j peg w ) an die Empf angsapplika- 
tion UAB des Benutzers mit der Adresse xyz@siemens.de. 
Die zu diesem Zweck benutzte WAP Nachricht M-Send. req 
5 tragt beispielsweise die Transaktion-Identitatsnummer 

ID10. Das Netzwerkelement RSA vergibt daraufhin eine in- 
dividuelle Identif ikationsnummer fur die gesendete MM A 
und bestatigt mit der WAP Nachricht M-Send. conf f daS die 
WAP Nachricht M-Send. req fehlerfrei an das Netzwerkele- 
10 ment RSA ubertragen worden ist: 

M-Send. conf (Netzwerkelement RSA Sendeapplikation 
UAA) : 

15 X-Mms -Message -Type : m- send- conf 

X-Mns-Tra.nsa.ctl on - ID : 10 
X-Mms - Versi on : 1.0 
X-Mms -Response- Sta tus : ok 

Message-ID: AAAA. llll@mms -relay 01 . Siemens . de 

20 

In den beiden WAP Nachrichten M-Send. req und M-Send. conf 
kommt die gleiche Transaktion-Identitatsnummer (Transac- 
tion-ID) zum Einsatz. Damit kann die WAP Nachricht M- 
Send.conf mit der Nachrichtenidentif ikationsnummer an der 

25 Sendeapplikation UAA eindeutig den dazugehorigen WAP 

Nachrichten M-Send. req zugeordnet werden, wodurch die in- 
dividuelle Identif ikationsnummer AAAA . llll@mms- 
relay01.siemens.de der verschickten MM A zugeordnet werden 
kann. Das Netzwerkelement RSA hat fur die MM A in diesem 

30 Beispiel fur die Schnittstelle Sendeapplikation UAA / 

Netzwerkelement RSA die individuelle Identif ikationsnum- 
mer AAAA.IIIl@mr7is-relay02.siejmens.de vergeben. sie steht 
im Kopf-Feld Message-ID . 
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Beispiel 1: Riickruf (ohne Bedingung) 

Der Absender der MM A mochte diese (zwei Stunden spater) 
5 wieder zuriickruf en. Dies geschieht erf indungsgemaS mit 
Hilfe einer neuen MM B , die an den gleichen Empfanger ge- 
schickt wird, wie die MM A , die zuriickgeruf en werden soli. 
An dieser Stelle kommt vorteilhaf terweise in der WAP 
Nachricht M-send. req das gemaS der vorliegenden Erfindung 

10 neu definierte Kopf-Feld mit der zweckmaSigen Bezeichnung 
X~Mms-Reca.ll -ID zum Einsatz, in das die Message-ID der 
MM A , die zuriickgeruf en werden soil, eingetragen wird (ID1 
in Fig. 2) . AuEerdem enthalt die WAP Nachricht M-Send. req 
vorteilhaf terweise das ebenfalls gemaE der vorliegenden 

15 Erfindung neu definierte Kopf-Feld mit der zweckmaSigen 
Bezeichnung X-Mms -Reques t -Report, mit dem eine Riickmel- 
dung iiber den erteilten Riickruf -Auftrag angefordert wer- 
den kann. In der WAP Nachricht M- Send, req sind bei einem 
Riickruf -Auft rag vorzugsweise nur die Kopf-Felder und kein 

20 weiterer multimedialer Inhalt ( „Message-Body u ) enthalten. 
Wie auch im folgenden sind die neu definierten Kopf- 
Felder umrahmt . 

M-Send.req (Sendeapplikation UAA Netzwerkelement RSA) : 

25 

X-Mms -Message - Type : m-send-req 
X-Mms - Transact! on -ID: 16 
X-Mms - Versi on: 2.0 

Date: Thu, 26 Oct 2000 14:12:19 +0100 
30 From : abc@sal . si emens . de 

To : jcyz@sal . si emens . de 
X-Mms-Recall-ID: AAAA. llll@mms- 
relay 01 . Siemens. de 
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X-Mms -Request -Report : Yes 

Subject: recall of multimedia, message a 

Content - Type : text/plain 

5 Auch der Empfang der WAP Nachricht M-Send. reqr mit dern 
Ruckruf -Bef ehl in MM B wird vorteilhaf terweise vom Netz- 
werkelement RSA umgehend mit einer WAP Nachricht M- 
Send. conf quittiert. In ihr ist die vom Netzwerkelement 
RSA vergebene Nachrichtenidentif ikationsnummer fiir die 

10 MM B (hier: AAAA . 2222@mms -relayOl . si emens . de) enthalten. 
Ferner enthalt sie vorteilhaf terweise das gemafi der vor- 
liegenden Erfindung neu definierte Kopf-Feld X-Mms- 
Supported- Feature, mit dessen Hilfe der Sendeapplikation 
UAA angezeigt werden kann, ob der Dienstanbieter A das 

15 Ruckruf -Dienstmerkmal unterstutzt (wie hier gezeigt) oder 
nicht . 

M-Send. conf (Netzwerkelement RSA Sendeapplikation 
UAA) : 

20 

X-Mms -Message - Type : m-send- conf 
X-Mms - Transact! on - ID : 1 6 
X-Mms - Versi on: 1.0 
X-Mms -Response -Sta tus : ok 
25 Message-ID: AAAA.2222@itwns-relay01.siemens.de 

X-Mms - Supported- Feature : recall 



Beim Austausch von WAP Nachrichten auf der Empf angsseite 
(Schnitts telle zwischen Netzwerkelement RSB und Empfangs- 
30 applikation UAB) muE unterschieden werden, ob die Emp- 
f angsapplikation UAB 

1. noch nicht uber eine eingetrof f ene MM informiert wor- 
den ist, oder 
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2. zwar benachrichtigt worden ist, aber die MM noch 
nicht abgerufen hat, oder 

3. die MM schon erhalten hat. 

5 Im ersten und zweiten Fall konnen die MM A und auch die 

MMb f die den Rxickruf -Bef ehl enthalt, im Zustandigkeitsbe- 
reich des Dienstanbieters B (MMSE B ) geloscht werden. Im 
ersten Fall muS der Empfanger davon nicht einmal in 
Kenntnis gesetzt werden. Im zweiten Fall sollte die Emp- 

10 f angsapplikation UAB hingegen durch den Dienstanbieter B 
vorzugsweise daruber informiert werden konnen, daS die 
MM A nicht mehr langer zum Herunterladen fur ihn bereit 
liegt, wenn der Absender sie nachtraglich zuruckgeruf en 
hat. Dazu kann gemaS dieser Erfindung die WAP Nachricht 

15 M-Notifica.tion.ind benutzt werden: 



2. Fall: M-Notification. ind (Netzwerkelement RSB Emp- 
f angsapplikation UAB) : 

20 X-Mms -Message - Type : m -notifi cation- ind 

X-Mms - Transact i on- ID: 20 

X-Mms - Versi on: 1.0 

From : abc@sal . Siemens . de 

X-Mms -Message -Class : Personal 
25 X-Mms-Message-Size: 42 

X-Mms -Expiry : 360 0 

X-Mms - Conten t-Location: http: //mms - 
relay 02 . Siemens . de/default- recall -message 



30 



X-Mms -Recalled-URI : http: //mms - 
relay 02 . Siemens . de/BBBB .3333 

X-Mms -Date-Of -Execution: Thu, 26 Oct 2000 14:14:54 
+ 0100 
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In der WAP Nachricht M-Notification.ind kann fur die I- 
dentif izierung der zuriickgeruf enen MM A nur der URI be- 
nutzt werden, da das Netzwerkelement RS zu diesem Zeit- 
punkt noch keine „Message-ID" fur die zuriickgeruf ene MM A 
5 vergeben hat (dies geschieht erst mit dem Herunterladen) . 
Die Kopf-Feld X-Mms -Recalled-URI und X-Mms -Date- Of - 
Execution unterscheiden diese Ruckruf -Benachrichtigung 
von einer ff herk6mmlichen w Benachrichtigung. Das Kopf-Feld 
X-Mms -Content-Location verweist in diesem Beispiel auf 

10 einen URI, unter dessen Speicherplatz vorteilhaf terweise 
eine Standard-Text -Nachricht des Dienstanbieters B (z. 
B.: „Die MM ist vom Absender wieder geloscht worden.N zu 
finden ist. Damit konnen auch Sende- und/oder Empf angsap- 
plikationen, die die neuen Kopf-Felder des Ruckruf- 

15 Dienstmerkmals nicht verstehen, nachtraglich iiber einen 
ausgefuhrten Ruckruf -Auf trag informiert werden. 

Mit der WAP Nachrichten M-NotifyResp.req wird der korrek- 
te Empfang der WAP Nachricht M-Notifica.tion.ind besta- 

20 tigt. Das Kopf-Feld X-Mms-Status tragt in diesem Beispiel 
einen der gemaS der vorliegenden Erfindung neu definier- 
ten Eintrage (namlich „recall feature supported") , mit 
dem das Netzwerkelement RSB dariiber in Kenntnis gesetzt 
werden kann, da£ die Empf angsapplikation UAB die zweite 

25 Benachrichtigung mit der Information iiber den Ruckruf 
verstanden hat . 

(noch) 2. Fall: M-NotifyResp.req (Empf angsapplikation UAB 
— > Netzwerkelement RSB) : 

30 

X-Mms -Message - Type : m-noti fyresp - reg 
X-Mms -Transaction- ID : 20 
X-Mms -Version: 1.0 
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X-Mms -Status : recall feature supported 



Wenn aber die MM A , die geloscht werden soli, bereits an 
5 die Empf angsapplikation UAB iibermittelt worden ist (dri ti- 
ter Fall) , beinhaltet vorteilhaf terweise die WAP Nach- 
richt M-Notlfication. ind zweckmafiigerweise nicht die Be- 
nachrichtigung iiber den bereits erfolgten Ruckruf , son- 
dern den Ruckruf -Befehl selbst und zwar in Form des Kopf- 

10 Feldes mit der zweckmafiigen Bezeichnung X-Mms -Recall -ID, 
in dem die Identif ikationsnummer der MM A eingetragen 
wird, die zuriickgeruf en werden soli. Hier wird vorzugs- 
weise die Identif ikationsnummer (und nicht der URI) be- 
nutzt, weil sie (in dem hier beschriebenen dritten Fall) 

15 nach dem zuvor erfolgten Herunterladen sowohl dem Netz- 
werkelement RSB als auch dem Empf angsapplikation UAB be- 
kannt ist. 

3. Fall: M-Notification. ind (Net zwerkelement RSB — » Emp- 
20 f angsapplikation UAB) : 

X-Mms -Message - Type : m -no tification-ind 
X-Mms - Transa ction- ID : 2 5 
X-Mms -Version: 1.0 
25 From : abc@sal . Siemens . de 

X-Mms -Message - Class : Personal 
X-Mms -Message -Size: 42 
X-Mms -Expiry: 3600 

X-Mms - Con ten t -Loca ti on: ht tp : //mms - 
30 relay 02 . Siemens . de/ default- recall -message 

X-Mms-Recall-ID: BBBB . 3333@mms~ 
relay 02 . Siemens . de 
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Das Kopf-Feld X-Mms -Content -Location verweist in diesem 
Beispiel auf einen URI, unter dessen Speicherplatz eine 
Standard-Text -Nachricht des Dienstanbieters B (z.B.: w Der 
Absender mochte die MM mit der Message -ID BBBB . 3333@mms- 
5 relay02.siemens.de zuriickrufen. tt ) zu finden ist. Damit 
konnen auch Sende- und/oder Empf angsapplikationen, die 
die neuen Kopf-Felder des Ruckruf-Dienstmerkmals nicht 
verstehen, nachtraglich. liber einen vom Absender ver- 
schickten Ruckruf -Auf trag informiert werden. 

Urn hervorzuheben, daS die MM A an dieser Schnittstelle ei- 
ne andere „ Message -ID" tragen kann, wurde in diesem Aus- 
fuhrungsbeispiel als Wert BBBB . 3333@mms- 
irelay02.siemens.de gewahlt (entspricht ID2 von MM A in 
Fig. 2) . 

(noch) 3. Fall: M-NotifyResp.req (Empf angsapplikation UAB 
— » Netzwerkelement RSB) : 

X-Mms -Message - Type : m-notifyresp-req 
X-Mms -Transaction- ID : 25 
X-Mms -Version : 1.0 
X~Mms- Status : recall successful 



Die Empf angsapplikation UAB schickt bei diesem Ausftih- 
rungsbeispiel mit der WAP Nachricht M-NotifyResp.req eine 
Ruckmeldung zuriick an das Netzwerkelement RSB. Dazu wird 
vorteilhaf terweise das in dieser Erfindung erweiterte 
Kopf-Feld X-Mms -Status aus dem Encapsulation- Standard 
(s.o.) benutzt. In diesem Ausf uhrungsbeispiel konnte die 
MM A auf der Empf angsapplikation UAB geloscht werden, was 
mit dem Feld-Wert „ recall successful'' ausgedruckt wird. 
Im Netzwerkelement RSB kann der Transact! on -ID (hier: 25) 
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des WAP Nachrichten-Paares auf die Nachrichtenidentif ika- 
tionsnummer (hier : BBBB. 333 3@mms-relay0 2 . Siemens .de) der 
geloschten MM A geschlossen werden. Dadurch ist das Ver- 
fassen einer Ruckmeldung moglich, falls dies vom Absender 
5 gewiinscht und vom Dienstanbieter B unterstiitzt wird. 

M-Delivery. ind (Netzwerkelement RSA Sendeapplikation 
UAA) : 



10 X-Mms -Message - Type : m- delivery- ind 

X-Mms -Message-ID: AAAA.2222@mms-rela.y01 . Siemens .de 

X-Mms - Versi on: 1.0 

To : abc@sal . si emens . de 

Date: Thu, 26. Oct 2000 14:14:09 +0100 



15 



X -Mms -Status : recall successful 



Falls der Absender eine Ruckmeldung fur den von ihm ini- 
tiierten Riickruf -Auf trag wiinscht, kann das MMS Re- 
lay/Server A mit der WAP Nachricht M-Delivery. ind eine 

20 Ruckmeldung zuriick an die Sendeapplikation UAA schicken. 
In dem Feld „Message~ID" steht die Identif ikationsnummmer 
des Ruckruf -Auf trages . Fur den Status des Riickruf es wird 
t hier ebenfalls vorteilhaf terweise das erweiterte Kopf- 
Feld X-Mms -Status benutzt, in dem das erfolgreiche L6- 

25 schen der MM A mit dem Feld-Wert „ recall successful w bes- 
tatigt wird. Da der Sendeapplikation UAA der Zusammenhang 
zwischen der Nachrichtenidentif ikationsnummer des Ruck- 
ruf -Auf trages und der Nachrichtenidentif ikationsnummer 
der MM A/ die zuriickgeruf en werden sollte, bekannt ist, 

30 kann dem Absender mitgeteilt werden, ob sein Riickruf - 

Auftrag erfolgreich ausgefuhrt werden konnte oder nicht 
(sofern die beteiligten MMS Dienstanbieter dies unter- 
stutzen) . 
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Beispiel 2: Andern (ohne Bedingung) 

In diesem Beispiel mochte der Absender seine MM A (eine 
5 Stunde nach dem Verschicken) aktualisieren : Von den ur- 
sprunglichen verschickten zwei Elementen soil nur noch 
das JPEG-Bild (MIME content type „ image/ j peg w } erhalten 
bleiben. AuSerdem soli der Betreff in „Agenda fur unser 
Meeting * geandert werden. 

10 

Gemafi dieser Erfindung wird eine neue MM B an den gleichen 
Empf anger geschickt wie die zuvor verschickte MM A , die 
geandert bzw. ersetzt werden soil. Dazu wird vorteilhaf t- 
erweise das gemafi der vorliegenden Erfindung neu defi- 
15 nierte Kopf-Feld mit der zweckmafiigen Bezeichnung X-Mms- 
Replace-ID benutzt, in das die „ Message- ID* der MM A ein- 
getragen wird. Aufeerdem enthalt vorteilhaf terweise die 
WAP Nachricht M-Send. req das ebenfalls gemag der vorlie- 
genden Erfindung neu definierte Kopf-Feld mit der zweck- 
mafeigen Bezeichnung X-Mms -Reques t -Report, mit dem eine 
Riickmeldung iiber den erteilten Anderungsauf trag angefor- 
dert werden kann (wie in diesem Beispiel gezeigt) . 

M-Send.req (Sendeapplikation UAA -» Netzwerkelement RSA) : 

X-Mms -Message - Type ; m-send- req 
X-Mms - Trans a. ction-ID: 32 
X-Mms -Version: 1.0 

Date: Thu, 26 Oct 2000 13:12:11 +0100 
From : abc@sal . si emens . de 
To ; xyz@sal . si emens . de 
X-Mms -Replace -ID: AAAA . llll@mms- 
relayOl . Siemens . de 



WO 02/063839 



79 



PCT/EP02/00571 



X-Mms -Request -Report : Yes 
Subject : Agenda fur unser Meeting 

Content- Type : mul tipart/ related; boundary^ " 

_=_NextPart___023_" 

5 

_=__NextPart_023_ 

Conten t - Type : image/ j peg; name= " agenda . jpg" 
Content -Transfer -Encoding : base64 
Con tent -ID: <1725782> 

_=_Nex:tPart_023_ - - 

Auch der Empfang dieser WAP Nachricht M~Send. req, welche 
die MM B mit dem Anderungsbef ehl in sich tragt, wird be- 
vorzugt vom Netzwerkelement RSA umgehend mit einer WAP 
Nachricht M-Send. conf quittiert . In ihr ist zweckmaBiger- 
weise die vom Netzwerkelement RSA vergebene Nachrichten- 
identif ikationsnummer (Message- ID) der MM B (hier: 
AAAA.5555@mz7is-relay01.sieziiens.de) und das ebenfalls gemaS 
der vorliegenden Erfindung neu definierte Kopf-Feld X- 
Mms- Supported- Feature enthalten, mit dessen Hilfe der 
Sendeapplikation UAA angezeigt werden kann, ob der 
Dienstanbieter A das Andern-Dienstmerkmal unterstiitzt o~ 
der nicht. Die beiden WAP Nachrichten tragen in diesem 
Beispiel die Transaktion-Identitatsnummer IDD32. 

M-Send. conf (Netzwerkelement RSA -> Sendeapplikation 
UAA) : 

X-Mms -Message- Type: m- send- conf 
X-Mms- Tra nsaction-ID: 32 
X-Mms - Versi on: 1.0 
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X-Mms -Response -Status : ok 

Message-ID: AAAA. 555 5@mms- relay 01 . Siemens . de 



X ~Mms - Suppor ted-Feature: repl ace 



5 Beim Austausch von WAP Nachrichten auf der Empf angsseite 
(Schnittstelle zwischen Netzwerkelement RSB und Empfangs- 
applikation UAB) muS unterschieden werden, ob die Emp- 
f angsapplikation UAB 

1 . noch nicht uber eine eingetrof f ene MM inf ormiert wor- 
10 den ist, oder 

2. zwar benachrichtigt worden ist, aber die MM noch 
nicht abgerufen hat, oder 

3. die MM schon erhalten hat. 



Im ersten und zweiten Fall kann die MM A im Zustandig- 
keitsbereich des Dienstanbieters B (MMSE B ) durch die MM B 
geandert, insbesondere ersetzt, werden . Die Erfindung er- 
moglicht, daS der Empf anger im ersten Fall sowohl bei der 
Benachrichtigung als auch beim Herunter laden daruber in 
Kenntnis gesetzt wird, da£ es sich urn eine nachtraglich 
geanderte, insbesondere ersetzte, MM handelt und wann der 
Anderungsauf t rag ausgefiihrt worden ist. Bevorzugt kann im 
zweiten Fall der Dienstanbieters B die Empf angsapplikati- 
on UAB sofort nach dem Ausfiihren des Anderungsauf t rages 
im MMSE B dariiber informieren, daS der Absender MM A durch 
eine neue MM B aktualisiert hat und wann diese Aktualisie- 
rung vorgenommen worden ist. Nach dieser Erfindung soil 
diese Benachrichtigung vorzugsweise mittels der WAP Nach- 
richt M-Notification. ind erfolgen, in der fur die I dent i- 
fizierung der geandert en, insbesondere ersetzt en, MM A nur 
der URI benutzt werden kann, da das Netzwerkelement RSB 
zu diesem Zeitpunkt noch keine Nachrichtenidentif ikati- 
onsnummer {„Message- ID XX ) fur die MM A vergeben hat (dies 
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geschieht erst mit dem Herunter laden der MM A ) . Die Kopf- 
Felder X-Mms -Replaced-URI und X-Mms -Date -Of -Execution un- 
terscheiden diese Ruckruf -Benachrichtigung von einer 
„herk6mmlichen n Benachrichtigung. Das Kopf-Feld X-Mms - 
5 Content-Location zeigt an, wo die MM B mit dem nun aktuel- 
len Inhalt auf dem Server zu finden ist. 

2. Fall: M-Notification.ind (Netzwerkelement RSB -» Emp- 
f angsapplikation UAB) : 

0 

X-Mms -Message - Type : m -no ti fi ca ti on-ind 
X-Mms - Trans a ction-ID: 35 
X-Mms - Versi on: 2.0 
From : abc@sal . si emens . de 
5 X-Mms -Message-Class : Personal 

X-Mms -Message-Si ze: 45 
X-Mms -Expiry : 3 600 

X-Mms -Content-Location : http : //mms- 
relay02 . Siemens . de/BBBB. 4444 
3 X-Mms -Replaced-URI : http: //mms- 

relay02 . Siemens .de/BBBB. 3333 

X-Mms -Date-Of -Execution: Thu, 26 Oct 2000 13:15:09 
-¥0100 



Mit der WAP Nachricht M-JVotify.Resp.reg wird vorteilhaft- 
erweise der korrekte Empfang der WAP Nachricht M- 
Notification. ind von der Empf angsapplikation UAB besta- 
tigt, vgl. Fig. 2. Das Kopf-Feld X-Mms-Status tragt in 
diesem Beispiel einen gemaS der vorliegenden Erfindung 
neu definierten Eintrag (namlich „ replace feature suppor- 
ted") , mit dem das Netzwerkelement RSB dariiber in Kennt- 
nis gesetzt wird, dafi die Empf angsapplikation UAB die 
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zweite Benachrichtigung mit der Information uber den aus- 
gefuhrten Anderungsauf trag verstanden hat. 

(noch) 2. Fall: M-NotifyResp. req (Empf angsapplikation UAB 
-> Netzwerkelement RSB) : 

X-Mms -Message -Type: m-notifyresp-req 
X-Mms - Trans a ction-ID: 35 
X-Mms -Version: 1.0 

X-Mms - Status : replace feature supported 



Wenn aber die MM A , die geandert werden soli, bereits an 
die Empf angsapplikation UAB ubermittelt worden ist (drit- 
ter Fall) , beinhaltet nach dieser Erfindung die WAP Nach- 
richt M-Notification. ind vorteilhaf terweise nicht die Be- 
nachrichtigung uber eine bereits erfolgte Anderung, son- 
dern den Anderungsbef ehl selbst und zwar in Form des 
Kopf-Feldes mit der zweckmaEigen Bezeichnung X-Mms - 
Replace-ID, in dem die Identif ikationsnummer der zu an- 
dernden, insbesondere zu ersetzenden ; MM A eingetragen 
wird. Daraufhin kann von der Empf angsapplikation UAB das 
Herunterladen der MM B entweder im PUSH-Modus oder im 
PULL-Modus mit Hilfe des WSP GET Befehls eingeleitet wer- 
den. Das Kopf-Feld X-Mms-Content-Location verweist in 
diesem Beispiel auf einen URI , unter dessen Speicherplatz 
eine Standard-Text -Nachricht des Dienstanbieters B (z. 
B.: „Der Absender mochte die MM mit der Message-ID 
BBBB . 3333@mms-relay02 . Siemens . de nachtraglich andern. *) 
zu finden ist. Damit konnen auch Empf angsapplikationen, 
die die neuen Kopf-Felder des Ruckruf -Dienstmerkmals 
nicht verstehen, nachtraglich uber einen vom Absender 
verschickten Anderungsauf trag informiert werden. 
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3. Fall: M-Notification. ind (Netzwerkelement RSB -> Emp- 
f angsapplikation UAB) : 

X-Mms -Message - Type : m -no ti fication- ind 
5 X-Mms -Transaction- ID: 38 

X-Mms - Versi on: 1.0 
From : abc@sal . Siemens . de 
X-Mms -Message -Class : Personal 
X-Mms -Message -Size: 45 
10 X-Mms -Expiry : 3 600 

X-Mms - Con ten t-Loca ti on: ht tp : / /mms - 

relay 02 . Siemens • de/ default-replace -message 



X-Mms -Replace -ID: BBBB . 3333@mms - 
relay02 . Siemens . de 



15 

Als Antwort auf den WSP GET Befehl, mit dem der URI an 
das Netzwerkelement RSB geschickt wird, erhalt die Emp- 
f angsapplikation UAB die MM B mit dem geanderten Titel und 
dem geanderten multimedialen Inhalt (nur noch ein JPEG- 

20 Bild) zum Andern bzw. Ersetzen von MM A in der WAP Nach- 
richt M-Retrieve . conf zugestellt. Auch in der WAP Nach- 
richt M- Retrieve, conf soil vorteilhaf terweise das Kopf- 
Feld mit der zweckmaEigen Bezeichnung X-Mms -Replace -ID 
erganzt werden. Damit kann direkt auf der Empf angsappli- 

25 kation UAB die MM A durch die MM B geandert , insbesondere 
ersetzt, werden, falls die Empf angsapplikation UAB das 
Andern-Dienstmerkmal unterstiitzt. Abhangig vom gewahlten 
Zustel lungs -Modus wird in der WAP Nachricht M- 
Retrieve.conf die Transaktions-Identitatsnummer aus der 

30 WAP Nachricht M-Notification . ind ubernommen (PUSH-Modus) 
oder eine neue vergeben (PULL -Modus) . 
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(noch) 3. Pall: M-Retrieve . conf (Netzwerkelement RSB -» 
Empf angsapplikation UAB) : 

X-Mms -Message - Type : m-re tri eve - conf 
5 X-Mms -Transaction- ID: 38 bzw. 48 

Message- ID: BBBB. 4444@mms -relay 02 . Siemens . de 
X-Mms - Versi on: 1.0 

Date: Thu, 26 Oct 2000 13:12:11 +0100 
From : abc@sal . si emens . de 
10 X-Mms-Message-Class : Personal 

X-Mms -Message -Size: 42 
X-Mms-Expiry: 3600 



X-Mms -Replace-ID: BBBB . 3333@mms- 
relay 02 . Siemens . de 



15 Subject: Agenda fur unser Meeting 

Content-Type : mul tipart/ related; boundary= " • 
__j=J$extPart_023_ " 

_=_NextPart_023_ 

20 Content-Type: image/ jpeg ; name= " agenda . jpg n 

Content -Transfer -Encoding: base64 
Content-ID: < 17257 82> 



25 _=_NextPart_023_- - 

Urn hervor zuheben , daS die MM A an dieser Schnittstelle ei- 
ne andere Nachrichtenidentif ikationsnummer ( „ Message -ID" ) 
tragen kann, wurde in diesem Ausf uhrungsbei spiel als Wert 
30 BBBB. 3333@mms- relay 02 . Siemens .de gewahlt (entspricht ID2 
in Fig. 2) . 

Bei Zustellung von MM B im PULL-Mo&us : 
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3. Fall: M- Acknowledge . ind (Empf angsapplikation UAB -> 



Netzwerkelement RSB) : 



5 



X-Mms -Message - Type : m-acknowl edge -ind 
X-Mms - Transaction -ID: 48 



X-Mms - Vers! on: 1. 0 

X-Mms -Status : replace successful 



Erfolgte die Zustellung der MM B im PULL-Modus , schickt 
10 die Empf angsapplikation UAB vorzugsweise mit der WAP 
Nachricht M -Acknowledge . ind eine Ruckmeldung zuriick an 
das Netzwerkelement RSB. Dazu wird das gemaS dieser Er- 
findung erweiterte Kopf-Feld X-Mms-Status benutzt. In 
diesem Ausf uhrungsbeispiel konnte die MM A auf der Emp- 
15 f angsapplikation UAB durch die neue MM B ersetzt werden, 
was mit dem Feld-Wert „ replace successful " ausgedriickt 
wird. Im Netzwerkelement RSB kann von der Transaktions-ID 
( Transaction -ID) (hier: 48) des WAP Nachrichten-Paares M- 
Retrieve . conf und M-Acknol edge . ind auf die Nacfrrichten-ID 
20 (hier: BBBB.3333@mms-relay02.siemens.de) der ersetzten 
MM A geschlossen werden. Dadurch ist das Verfassen einer 
Ruckmeldung moglich, falls dies vom Absender verlangt und 
vom Dienstanbieter B unterstutzt wird. 

25 Bei Zustellung von MM B im PUSH-Modus 

3. Fall: M-NotifyResp.req (Empf angsapplikation UAB — > 
Netzwerkelement RSB) : 



X-Mms -Message - Type : m -no ti fyresp - req 



30 



X-Mms - Transact! on -ID: 3 8 



X-Mms -Version: 1.0 



X-Mms-Status : replace successful 
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Erfolgte die Zustellung der MM B im PUSH -Modus, bestatigt 
die Empfangsapplikation UAB den korrekten Empfang von MM B 
vorzugsweise mit der WAP Nachricht M-NotifyResp.req. Dazu 
wird bevorzugt das in dieser Erfindung erweiterte Kopf- 

5 Feld X-Mms-Status benutzt . In diesem Ausf uhrungsbeispiel 
konnte die MM A auf der Empfangsapplikation UAB durch die 
neue MM B ersetzt werden, was mit dem Feld-Wert „ replace 
successful * ausgedruckt wird. Im Netzwerkelement RSB kann 
von der Transaktions-ID (hier: 38) des WAP Nachrichten- 

10 Triples M-Notification . ind M-Retrieve . conf und M- 
NotifyResp.req auf die Nachrichten-ID (hier: 
BBBB. 333 3®mms- relay 02 . Siemens * de) der ersetzten MM A ge- 
schlossen werden. Dadurch ist das Verfassen einer Riick- 
meldung moglich, falls dies vom Absender verlangt und vom 

15 Dienstanbieter B unterstutzt wird. 



M-Delivery* ind (Netzwerkelement RSA -> Sendeapplikation 
UAA) : 



20 X-Mms -Message -Type : m~ delivery -ind 

X-Mms -Message-ID: AAAA. 5555@mms -relayOl . sieinens.de 

X-Mms - Versi on: 1.0 

To : abc@sal . si emens . de 

Date; Thu, 26 Oct 2000 13:12:11 +0100 



25 



X-Mms -Status: replace successful 



Das Netzwerkelement RSA kann mit der WAP Nachricht M- 
Delivery.ind eine Ruckmeldung zuruck an die Sendeapplika- 
tion UAA schicken. In dem Peld Message-ID steht die ID 
30 des Anderungsauf trages . Fur den Status des Anderungsauf - 
trages wird hier vorzugsweise ebenfalls das erweiterte 
Kopf-Feld X-Mms -Status benutzt, in dem das erfolgreiche 
Andern der MM A durch MM B mit dem Feld-Wert „ replace sue- 
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cessful" bestatigt wird. Da der Sendeapplikation UAA der 
Zusammenhang zwischen der Nachrichten-ID des Anderungs- 
auftrages und der Nachrichten-ID der MM A , die zuruckgeru- 
fen werden sollte, bekannt ist, kann dem Absender mitge- 
5 teilt werden, ob sein Ande rungs auft rag erfolgreich ausge 
fuhrt werden konnte oder nicht (sofern die beteiligten 
Dienstanbieter dies unterstutzen) . 

0 Beispiel 3 : Alternative fiir das Ubermitteln einer Status 
Information (ohne Bedingung) 

In den beiden zuvor beschriebenen Ausf uhrungsbeispielen 
wird eine Ruckmeldung uber den Ausgang eines erteilten 

5 Ruckruf- bzw. Anderungsauf trages von der Empf angsapplika 
tion UAB zum Netzwerkelement RSB (bei Dienstanbieter B) 
mit den WAP Nachrichten M-NotifyResp.ind (PUSH-Modus) o- 
der M- Acknowledgement . ind ( PULL- Modus ) , bzw. vom Netz- 
werkelement RSA zur Sendeapplikation UAA (bei Dienstan- 

0 bieter A) mit der WAP Nachricht M-Delivery. ind ubertra- 
gen. Dazu warden neue Feld-Werte in das Kopf-Feld X-Mzns- 
Status eingefuhrt. Dieses Vorgehen ist zwar effizient, 
jedoch nicht ganz konform zur bisherigen Nutzung des 
Kopf-Feldes X-Mms -Status . Deshalb wird im folgenden ein 

5 alternatives Ausf uhrungsbeispiel fur das Ubermitteln ei- 
ner Ruckmeldung beschrieben. Das Absenden sowie das Aus- 
fuhren eines Ruckruf- oder Anderungsauf trages bleibt da- 
bei wie in Beispiel 1 und Beispiel 2 beschrieben zweckma 
Sigerweise unverandert . 

0 

Mit dieser Alternative wird das Kopf-Feld X-Mns -Status 
(so wie es im Encapsulation Standard (s.o.) ursprunglich 
vorgesehen ist) weiterhin ausschlieSlich dazu benutzt, 
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den Absender iiber den Zustand der zuletzt verschickten MM 
(also derjenigen, die den Riickruf- oder Anderungsauf trag 
beinhaltete) zu informieren und nicht (wie unter Ausfiih- 
rungsbeispiel 1 und 2 beschrieben) iiber den Ausgang eines 
5 Riickruf- oder Anderungsauf trages . Fur diesen Fall wird 

deshalb ein weiteres Kopf-Feld definiert, mit dem der Ab- 
sender uber den Ausgang seines Riickruf- oder Anderungs- 
auf trages in Kenntnis gesetzt werden kann. Es wird vorge- 
schlagen, dieses neue Kopf-Feld mit dem Namen X-Mms- 
10 Original -Message-Status zu versehen und ihm die hexadezi- 
male Kodierung 0x8 6 (dezimal: 134) zu geben. Weiterhin 
wird vorgeschlagen, z.B. als Feld-Werte <Octetl28> fur 
„Die MM wurde erfolgreich zuriickgeruf en u , <Octetl29> fur 
„Der Riickruf der MM ist f ehlgeschlagen" , <Octetl30> fiir 
„Die MM wurde erfolgreich geandert bzw. ersetzt" und 
<Octetl31> fur ff Das Andern bzw. Ersetzen der MM ist fehl- 
geschlagen" zu benutzen. Fig. 7 zeigt das in dieser Al- 
ternative vorgestellte Kopf-Feld. 

Beispiel 4: Alternative fiir das Ubermitteln einer Riick- 
meldung (ohne Bedingung) 

In den Beispielen 1 und 2 wurde die MM A , auf die sich die 
Riickmeldung bezieht, iiber das Ergebnis des Riickruf- bzw. 
Anderungsauf trages anhand der Message- ID von MM B und an- 
hand der Transaktion-IDs in den WAP Nachrichten M- 
NotifyResp. ind oder M~ Acknowledge . ind identif iziert . 

Denkbar ist auch, die Nachrichten- ID derjenigen MM A/ die 
zuriickgeruf en oder geandert, insbesondere ersetzt, worden 
ist, direkt mit den WAP Nachrichten M-NotifyResp.ind oder 
M-Acknowledgement. ind (an Dienstanbieter B) , bzw. M- 
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Delivery . ind (von Dienstanbieter A) zu ubertragen. Dazu 
wird vorgeschlagen, ein neues Kopf-Feld einzufuhren, wel- 
ches beispielsweise die zweckmafiige Bezeichnung X-Mms- 
Original -Message- ID tragt, und ihm die hexadezimale Ko- 
5 dierung 0x8 7 (dezimal: 13 5) zu geben. Die Feld-Werte die- 
ses neuen Kopf-Feldes beinhalten bevorzugt die Nachrich- 
ten-ID der Original ~MM A und werden gemaS dem Encapsulati- 
on-Standard (s.o.) als Text-String kodiert . Fig. 8 zeigt 
das in dieser Alternative vorgestellte Kopf-Feld. 



C.2 Mit Bedingung fur Riickruf bzw. Andern 

In den nun folgenden Ausf uhrungsbeispielen wird detail - 
liert auf die in den WAP Nachrichten benutzten Kopf- 
Felder fur das bedingte Ruckrufen und Andern einer ersten 
Nachricht eingegangen. Dabei wird beispielhaft folgendes 
Szenario angenoramen: Eine MMS VAS-Applikation A ver- 
schickt eine MM A an einen Empfanger und will diese spater 
zuruckrufen (Beispiel 5) bzw. durch eine neue MM B erset- 
zen (Beispiel 6) . 

Innerhalb der WAP Nachricht M-Send. conf wird der gesende- 
ten MM A eine individuelle Identif ikationsnummer 
(AAAA. Ill l@mms- relay 01 . Siemens . de) zugeordnet . Diese 
Nachrichten ID 1 („ Message -ID 1 U J dient dazu, die MM A 
beim Zuruckrufen und Ersetzen zu identif izieren, s.o. Re- 
port of the 3GPP TSG-T2 SWG3 MMS. 

Beispiel 5: Bedingter Riickruf 

Der Absender einer MM A mochte diese (zwei Stunden spater) 
wieder zuruckrufen. Dies geschieht mit Hilfe einer neuen 
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MM B , die an den gleichen Empf anger geschickt wird, wie 
die MM A , die zuruckgerufen werden soil. An dieser Stelle 
wird in der WAP Nachricht M-send.req vorteilhaf terweise 
das Kopf-Feld X-Mms -Recall -ID mit der entsprechenden 
5 Nachricht en- ID der zuruckzuruf enden MM A verwendet, s. 

Beispiel 1. Zudem wird hier eine Riickmeldung uber den er- 
teilten Riickruf -Auf trag mittels des Kopf-Feldes X -Mms- 
Reques t -Report angef ordert . Das gemaS dieser Erfindung 
neu definierte Kopf-Feld mit der Bezeichnung X-Mms - 

10 Recall-Cond kommt in der WAP Nachricht M-Send.req zum 
Einsatz. Der Feld-Wert in diesem Beispiel wird als <Oc- 
tetl3 0> angenommen. Dieser Wert entspricht dem Wunsch des 
Absenders, den Riickruf nur zu realisieren, wenn die MM A 
nicht gelesen wurde, unabhangig davon, ob eine Benach- 

15 richtigung gesendet wurde oder ob die MM schon herunter- 
geladen wurde. 

M-Send.req (MMS VAS-Applikation A —> Netzwerkelement 
RSA) : 

20 



X-Mms -Message -Type : m-send-req 



X-Mms - Transact! on - ID : 1 6 



X-Mms - Versi on: 1.0 



Date: Thu, 26 Oct 2000 14:12:19 +0100 



25 



From : abc@vas . de 



To : xyz@siemens . de 

X-Mms-Recall -ID: AAAA. llll@mms- relay 01 . Siemens . de 
X-Mms -Reques t -Report : Yes 



X-Mms-Recall -Cond: Only before reading 



30 



Subject: recall of multimedia message a 
Content -Type: text/plain 



In 



diesem Fall sei angenommen, daS das Netzwerkelement 
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RSA feststellt, daS es die zu loschende MM an ein weite- 
res Netzwerkelement RSB weitergeleitet hat. Hier wird der 
Empfang der WAP Nachricht M-Send. req mit dem Riickruf- 
Befehl in MM B vom Netzwerkelement RSA mit einer WAP Nach- 

5 richt M-Send.conf quittiert (s.a. Fig. 2) . In ihr ist die 
vom Netzwerkelement RS vergebene Message- ID fur die MM B 
(hier: AAAA. 2222@mms -relay 01 . Siemens . de) enthalten. Fer- 
ner enthalt das Kopf-Feld X-Mms -Supported- Feature den in 
dieser Erf indungsmeldung neu definierten Eintrag „Beding- 

0 ter-Riickruf -Merkmal unterstutzt" . 

M-Send.conf (Netzwerkelement RSA -» MMS VAS-Applikation 
A) : 

5 X-Mms -Message - Type : m- send- con f 

X - Mm s - Iran sac t ion- ID : 16 
X-Mms -Version : 1.0 
X-Mms -Response- Status : ok 

Message-ID: AAAA. 2222@mms-relay01 . Siemens . de 
0 X-Mms- Supported - Feature : conditional recall 



Hier wird davon ausgegangen, da£ das Netzwerkelement RSB 
feststellt, daS die Empf angsapplikation UAB benachrich- 
tigt wurde und die MM abgerufen hat. Da die Bedingung des 
Riickrufs noch erfullt sein kann (MM sollte noch nicht ge- 
6f fnet/gelesen sein) , wird weiterhin versucht, den Riick- 
ruf-Auftrag zu erfullen. Dabei wird die Empf angsapplika- 
tion UAB mittels der WAP Nachricht M-Notification. ind in- 
formiert, daS die zuvor heruntergeladene MM A ' zuriickgeru- 
fen werden soil, wenn sie nicht gelesen wurde. Diese Be- 
dingung wird auch mittels des Kopf-Feldes X-Mms -Recall - 
Cond mit dem Feld-Wert <Octetl3 0> (fur das Zuruckrufen 
nur vor dem Lesen) mitgeteilt. 
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Die Identif ikation der Nachricht MM A erfolgt hier auch 
mittels der Identif ikationsnummer. Diese Kennung kann 
sich aber aufgrund des Weiterleitens zu einem anderen 
5 Netzwerkelement RS von der Message-ID 1 {AAAA. llll@mms- 
relay01.siemens.de) unterscheiden, s.o. WAP-2 09- 
MMSEncapsulation, Release 2000. In diesem Ausf uhrungsbei- 
spiel wurde daher eine andere Message-ID gewahlt : 
BBBB. 3333@mms-relay02 . Siemens . de. 

10 

Das Kopf-Feld X-Mms- Content -Location verweist in diesem 
Beispiel auf einen URI , unter dessen Speicherplatz eine 
Standard- Text -Nachricht des Dienstanbieters B (z. B . : 
„Der Absender mochte die MM mit der Message- ID 
15 BBBB . 3333@mms-relay02 . Siemens .de zuriickruf en . w ) zu finden 
ist. Damit konnen auch Empf angsapplikationen UAB , welche 
die neuen Kopf-Felder des Riickruf -Merkmals nicht verste- 
hen, nachtraglich uber einen vom Absender verschickten 
Riickruf -Auf trag informiert werden. 

20 

M-Notification.ind (Netzwerkelement RSB — > Empfangsap- 
pl ikation UAB) : 

X-Mms -Message - Type : m -notifi ca ti on - ind 
25 X-Mms -Transaction- ID : 20 

X-Mms -Version: 2.0 

From : abc@vas . de 

X-Mms -Message -Class: Personal 

X-Mms-Message-Size : 42 
30 X-Mms -Expiry : 3 600 

X-Mms - Conten t -Loca ti on: ht tp : //mms - 

relay02 . si emens . de/defaul t-recall -message 

X-Mms -Recall - ID : BBBB. 3333@mms -relay 02 . Siemens . de 
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X-Mms -Recall -Cond: Only before reading 



Mit der WAP Nachricht M-NotifyResp.ind wird der korrekte 
Empfang der WAP Nachricht M-Notification.ind bestatigt. 

5 Falls die MM A nicht gelesen wurde, kann diese infolge des 
bedingten Ruckruf befehls geloscht werden. Des weiteren 
berichtet die Empf angsapplikation UAB hier uber den Aus- 
gang des Ruckruf -Auftrags . Dazu dient der X-Mms-Status 
Kopf-Feld. Er tragt in diesem Beispiel einen der in die- 

10 ser Erf indungsmel dung neu definierten Eintrage, namlich 
<Octetl4 0> fur „ Ruckruf erfolgreich, bevor MM gelesen 
wurde w . 



M-NotifyResp. ind (Empf angsapplikation UAB — > Netzwerkele- 
15 ment RSB) : 

X-Mms -Message - Type : m-noti fyresp ~ind 
X~Mms - Transact! on -ID : 2 0 
X-Mms -Version: 2.0 



20 



X-Mms -Status : Recall successful , before MM has been 
read 



Falls die MM A/ die zuruckgeruf en werden soil, bereits ge- 
offnet wurde, wird nicht mehr versucht, diese zu loschen. 

25 Statt dessen beinhaltet die WAP Nachricht M- 

NotifyResp.ind die Information uber den MiKerfolg des 
Ruckruf vorgangs; da die MM A schon geoffnet wurde. Das 
Kopf-Feld X-Mms -Status hat dann den Wert <Octetl44> fur 
„Ruckruf f ehlgeschlagen, da MM gelessen wurde". Die M- 

30 NotifyResp. ind WAP Nachricht sieht dann f olgendermaSen 
aus : 



M-NotifyResp. ind (Empf angsapplikation UAB — > Netzwerkele- 
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merit RSB) : 

X~Mms -Message - Type : m -no tifyresp - ind 
X-Mms -Transaction- ID: 20 
5 X-Mms - Vers! on: 1.0 

X-Mms-Status : Recall failed, since MM has been 
read 



Falls der Absender eine Ruckmeldung fur den von ihm ini- 
10 tiierten Ruckruf -Auf t rag wunscht, kann das Netzwerkele- 
ment RSA mit der WAP Nachricht M-Delivery . ind eine Ruck- 
meldung zuriick an die Sendeapplikation UAA schicken. In 
dem Feld „ Message- ID" steht die ID des Ruckruf -Auf trages 
(AAAA. 2222@mms-relay01 . Siemens .de) . Fur den Status des 
15 Ruckrufes wird hier ebenfalls das erweiterte Kopf-Feld X- 
Mms -Status benutzt, in dem das z.B. erfolgreiche Loschen 
der MM A mit dem Feld- Wert „ Ruckruf erfolgreich, bevor MM 
gelesen wurde M bestatigt wird. Da der Sendeapplikation 
UAA der Zusammenhang zwischen der Nachrichten- ID des 
20 Ruckruf -Auf t rages und der Nachrichten- ID der MM A , die zu- 
ruckgerufen werden sollte, bekannt ist, kann dem Absender 
mitgeteilt werden, ob sein Ruckruf -Auf trag erfolgreich 
ausgefiihrt werden konnte oder nicht (sofern die beteilig- 
ten MMS Dienstanbieter dies unterstutzen) . 

25 

M-Delivery . ind (Netzwerkelement RSA -> Sendeapplikation 
UAA) : 

X-Mms -Message -Type : m- delivery -ind 
30 X-Mms -Message -ID: AAAA . 2222@mms -relayOl . siejmens.de 

X-Mms r- Vers! on: 1.0 
To : abc@vas . de 

Date: Thu, 26. Oct 2000 14:14:09 +0100 



WO 02/063839 



95 



PCT/EP02/00571 



X-Mms -Status : recall successful 



Beispiel 6: Bedingtes Andern bzw. Ersetzen 

5 

In diesem Beispiel mochte der Absender seine MM A (eine 
Stunde nach dem Verschicken) aktualisieren: Von den ur- 
sprunglich verschickten zwei Elementen soil nur noch das 
JPEG-Bild (MIME content type „ image/ jpeg" ) erhalten blei- 

10 ben. AuSerdem soil das Subject in „Agenda fur unser Mee- 
ting" geandert werden, s. Beispiel 2. An dieser Stelle 
wird in der WAP Nachricht M-send. req vorteilhaf terweise 
das Kopf-Feld X-Mms -Replace -ID mit der entsprechenden 
Nachrichten-ID der zu ersetzenden MM A verwendet . Zudem 

15 wird hier eine Ruckmeldung liber den erteilten Anderungs- 
auftrag mittels des X-Mms -Request-Report Kopf-Feldes an- 
gef ordert . Das in dieser Erf indungsmel dung neu definierte 
Kopf-Feld mit der beispielhaf ten Bezeichnung X-Mms - 
Replace-Cond kommt in der WAP Nachricht M-Send . req zum 

20 Einsatz. Der Feld-Wert in diesem Beispiel wird als <Oc- 

tetl2 8> angenommen. Dieser Wert entspricht dem Wunsch des 
Absender s, den Ruckruf nur dann zu realisieren, wenn der 
Empfanger der MM A uber diese Nachricht noch nicht benach- 
richtigt wurde . 

25 

M-Send. req (MMS VAS-Applikation A ~~» Netzwerkelement 
RSA) : 

X-Mms -Message-Type : m-send- req 
30 X-Mms -Transaction- ID: 32 

X-Mms - Vers! on: 1.0 

Date: Thu, 26 Oct 2000 14:12:19 +0100 
From : abc@ va s . de 
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To ; xyz@si emens . de 

X-Mms -Recall -ID: AAAA. llll@mms- relay 01 . Siemens . de 
X-Mms -Reques t -Report : Yes 

X-Mms -Recall -Cond: Only before notification 
5 Subject: Agenda fur unser Meeting 

Content -Type: multipart /related; boundary-" 

_=_NextPart_023__ " 

_=_NextPart_ m 023_ 

0 Content- Type : image/ jpeg; name= "agenda . jpg n 

Con tent- Tran s fer - En coding : base 6 4 
Content-ID: <1725782> 

5 = NextPart 023 



Im weiteren werden 2 Falle betrachtet : 

Fall 1: Empf angsapplikation UAB hat MM A auf grurid einer 
Benachrichtigung (Notification) heruntergeladen . 
Fall 2: Die MM A ist noch auf dem Netzwerkelement RSA und 
es wurde keine Benachrichtigung an die Empf angsapplikati- 
on UAB gesendet . 

Fall 1: 

Da die Benachrichtigung schon gesendet wurde, ist die Be- 
dingung zum Ausfiihren des Anderungsbef ehls nicht mehr er- 
fiillt. Folglich kann und soli das Ersetzen nicht mehr er- 
folgen. Hier wird der Empfang der WAP Nachricht M- 
Send.req mit dem Anderungsbef ehl vom MMS Relay/Server tnit 
einer WAP Nachricht M-Send.conf quittiert . In ihr ist die 
vom MMS Relay/Server vergebene Nachrichten~ID fur die MM B 
(hier: AAAA. 222 2@mms -relay 01 . siemens.de) enthalten. Fer- 
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ner enthalt das Kopf-Feld X-Mms -Supported-Feature den in 
dieser Erf indungsmeldung neu definierten Eintrag „Beding- 
tes-Andern-Merkmal unterstutzt " . Da der Anderungsauf trag 
nicht ausgefiihrt werden kann, wird der Auftraggeber mit- 
5 tels des Kopf -Feldes X-Mms -Response- Status uber den Aus- 
gang seines Auftrages inf ormiert : Der Feld-Wert <0c- 
tetl52> meldet, da£ das bedingte Ersetzen nicht erfolgen 
konnte, da die Benachrichtigung schon gesendet wurde : 
„Andern f ehlgeschlagen, da Benachrichtigung gesendet wur- 
10 de*. 

M-Send. conf (Netzwerkelement RSA MMS VAS-Applikation 
A) : 

15 X-Mms -Message-Type: m- send- conf 

X-Mms - Transact! on -ID: 32 
X-Mms - Versi on: 2.0 
X-Mms -Response-Status : ok 

Message -ID: AAAA . 2222@mms -relay 01 . Siemens . de 



20 



X-Mms- Supported- Fea ture : condi ti onal replace 
X-Mms-Status : replace failed, since notification was 
sent 



Falls das Netzwerkelement RSA das bedingte Ersetzen nicht 
25 unterstutzt, wird er die MM B als normale Multimedia Mes- 
sage behandeln und folglich wie ublich dem Empf anger wei- 
terleiten, ohne Rucksicht auf die zu ersetzende MM A zu 
nehmen . 



Fall 2: 

Da die Benachrichtigung noch nicht gesendet wurde, ist 
die Bedingung zum Ausfuhren des Anderungsbef ehls erfullt. 
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Folglich kann das Ersetzen wie gewunscht erfolgen. Die 
MM A kann auf dem Netzwerkelement RSA geloscht werden, und 
der Absender wird mittels des Kopf -Feldes X-Mms-Response- 
Status liber diesen Vorgang inf ormiert • Der Feld-Wert <Oc- 
5 tetl52> meldet, da£ das bedingte Ersetzen vor dem Versand 
der Benachrichtigung erfolgt ist: „Andern erfolgreich, 
vor Benachrichtigung " . 

M-Send. conf (Netzwerkelement RSA -> MMS VAS-Applikation 
10 A) : 



X-Mms -Message - Type : m -send - conf 
X-Mms - Transact! on - ID : 32 
X-Mms - Versi on: 2.0 
15 X-Mms -Response- Status : ok 

Message-ID: AAAA. 2222@mms-relay01 . Siemens . de 



20 



X-Mms -Supported -Feature : condi tional replace 
X-Mms-Status : replace successful , before not! fl- 
ea ti on 



Die neue Nachricht MM B erreicht dann die Empf angsapplika- 
tion UAB als normale Multimedia -Nachricht , die durch eine 
eigene Benachrichtigung angekiindigt wird. Der Empf anger 
wird somit inf ormiert, daS der Absender die zuvor ver- 
25 schickte MM A durch eine neue MM B ersetzt hat. 



Teil der Erfindung sind neben den beschriebenen Verfahren 
ebenfalls die entsprechenden Vorrichtungen, insbesondere 
30 Telekommunikationsendgerate und hierbei insbesondere Mo- 
bilfunkgerate sowie die entsprechenden Netzwerkelemente . 
Ebenso sind die entsprechenden Sof twareprogramme von der 
vorliegenden -Erf indung umf afit . 
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Erstes Okfcefct 


Mogiicne KoniDxna- 

+■* A on on 


Anzahl der 


0 . . .30 


31 


0 . . .30 


31 


1 


> 30 


32. . .127 (filr Text) 


96 


> 0 


128. . .255 


128 


0 



Tabelle 1: Moglichkeiten der Feld-Wert-Kodierung nach WAP- 
203-WSP, Version 4-May-2000; Wireless Application Protocol, 
Wireless Session Protocol Specification; Chapter 8.4: "Header 
Encoding" . 
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Name 


Inhalt 


Kommentare 


"X-Mms- 
Recall- 
ID" 


ID 


Optional . Diese ID SOLL immer 
vorhanden sein, wenn ein 
Absender eine zuvor versendete 
MM zurtickrufen will. Bezeichnet 
die Nachrichten-ID der MM, die 
ein Absender zuruckrufen will. 


tt X-Mms- 

Replace- 

ID" 


ID 


Optional. Diese ID SOLL immer 
vorhanden sein, wenn ein 
Absender eine zuvor versendete 
MM andern will. Bezeichnet die 
Nachrichten-ID der MM, die ein 
Absender andern will . 


u X-Mms- 

Request- 

Report" 


Ja j Nein 


Optional. Bezeichnet, ob der 
Absender einen Bericht daruber 
anfordert, ob ein Ruckruf- oder 
ein Anderungsauf trag erfolgreich 
ist oder nicht. 


"X-Mms- 
Recall- 
Cond" 


Nur vor Ben- 
achrichtigung | 
Nur vor Herun- 
terladen | Nur 
vor dem Lesen 
Auch nach dem 
Lesen 


Optional . Bezeichnet die Bedin- 
gungen, unter denen der Ruckruf 
aufgegeben ist. 


"X-Mms- 

Replace- 

Cond" 


Nur vor Ben- 
achrichtigung | 
Nur vor He run - 
terladen | Nur 
vor dem Lesen 
Auch nach dem 
Lesen 


Optional. Bezeichnet die Bedin- 
gungen, unter denen der Ruckruf 
aufgegeben ist . 
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Name 


Inhalt 


Kommentare 


"X-Mms- 


Riickruf | Andern 


Optional . 


Supported- 


| Keine Unter- 


Dieses Feld SOLL immer vor- 


Feature" 


stiitzung 


handen sein, urn anzuzeigen, 




Bedingter Ruck- 


ob ein Dienstanbieter fahig 




ruf | Bedingtes 


ist, ein oder mehrere der 




Andern 


Dienstmerkmale zu unterstflt- 
zen . 


"X-Mms- 


Riickruf erfol- 


Optional . 


Status" 


greich, vor Ben- 


Dieses Feld gibt den Status 




achrichtigung | 


der Riickruf- oder der 




Riickruf fehl- 


Anderungsopera t i on an . 




geschlagen, da 






Benachr i ch t i gung 






schon versendet 






| Andern erfol- 






greich, vor Ben- 






achrichtigung | 






Andern fehl- 






geschlagen, da 






Benachr icht i gung 






schon versendet 





Tabelle 3: Zusatzliche Einfugungen in die WAP Nachricht M- 
Send, conf . 
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Name 


Inhalt 


Kommentare 


"X-Mms- 
Replaced-URI" 


URI 


Optional . Bezeichnet ein nicht 
mehr gultiges URI, 


u X-Mms-Date- 
Of -Execution" 


Datum 


Optional . 

Bezeichnet das Datum, an dem 
ein Ruckruf- oder ein 
Anderungsauf trag ausgefiihrt 
wurde . 


tt X-Mms-Recall- 
ID" 


ID 


Optional . 

ID SOLL immer vorhanden sein, 
wenn ein Absender eine zuvor 
versendete MM zuruckrufen 
will, die schon an den 
Empf anger ausgeliefert wurde. 
Bezeichnet die Nachrichten-ID 
der MM, die ein Absender 
zuruckrufen will. 


u X-Mms- 
Replace-ID" 


ID 


Optional . 

ID SOLL immer vorhanden sein, 
wenn ein Absender eine zuvor 
versendete MM andern will, die 
schon an den Empf anger 
ausgeliefert wurde. 
Bezeichnet die Nachrichten-ID 
der MM, die der Absender 
andern will. 


u X-Mms-Recall- 


Nur vor dem 
xterunuenacien 
| Nur vor dem 
Lesen | Auch 
nach dem Le- 
sen 


Optional . 

Gibt die Bedingungen an, unter 
denen der Ruckruf aufgegeben 
ist . 
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u X-Mms- 


Nur vor dem 


Optional . 


Replace-Cond" 


Herunterladen 


Gibt die Bedingungen an, unter 




[ Nur vor dem 


denen der Ruckruf aufgegeben 




Lesen j Auch 


ist . 




nach dem Le- 






sen 





Tabelle 4: Zusatzliche Einfugungen in die WAP Nachricht JBf- 
Notification. ind. 
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Name 


Xnhalt 


Kommentare 


u X-Mms- 


Zuruckgewiesen | 


Zwingend . 


Status" 


He run terge laden j 


Nachrichtenstatus . 




Verschoben | 






Ruckruf erfolgreich | 






Ruckruf f ehlgeschlagen j 






Andern erfolgreich, vor 






dem Lesen | Andern 






f ehlgeschlagen, da . . . | 






D i ens tme rkma 1 Riickr u f 






unterstiitzt | 






Dienstmerkmal Andern 






unterstiitzt 





Tabelle 5: Zusatzliche Einfiigungen in die WAP Nachricht M- 
NotifyResp . req. 
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Name 


Inhalt 


Kommentare 


"X-Mms- 
Replace-ID" 


ID 


Optional . 

Die ID SOLL immer vorhanden 
sein, wenn ein Absender eine 
zuvor versendete MM andern 
will . Bezeichnet die 
Nachrichten-ID der MM, die der 
Absender andern will. 


"X-Mms- 
Status" 


Andern 
erfolgreich 


Optional . 

Zeigt an, ob eine Nachricht 
ersetzt wurde. 


w X-Mms»Date- 
Of- 

Execution'' 


Datum 


Optional . 

Gibt das Datum an, an dem die 
Rtickruf- oder die Anderungsop- 
eration durchgefuhrt wurde. 


u X-Mms- 

Replace- 

Cond" 


Nur vor dem Le- 
sen | Auch nach 
dem Lesen 


Optional . 

Gibt die Bedingungen an, unter 
denen der Andernbefehl aufge- 
geben ist ♦ 



Tabelle 6: Zusatzliche Einfiigungen in die WAP Nachricht M- 
Re tri eve . conf . 
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Name 


Inhalt 


Kommentare 


"X-Mms- 


Ruckruf 


Optional . 


Status" 


erf olgreich, 


Dieses Feld gibt den Status 




vor dem Lesen 


der Nachricht und der Ruckruf - 




| Ruckruf 


oder Anderungsoperation an. 




f ehlgeschlagen 






, da MM 






gelesen wurde 






1 Andern 






erfolgreich | 






Andern 






f ehlgeschlagen 

I ••• 





Tabelle 7: Zusatzliche Einfugungen in die WAP Nachricht M- 
Acknowl edge . ind . 
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Name 


Inhalt 


Kommentare 


X-Mms-Status 


Riickruf 


Zwingend. Status der 




erfolgreich, vor 


Nachricht und der Operation, 




dem Lesen | 






Riickruf 






f ehl ge s chl agen , 






da MM gelesen 






wurde | Andern 






erfolgreich 






Andern 






f ehlgeschlagen 





Tabelle 8: Zusatzliche Einfugungen in die WAP Nachricht M~ 
Delivery, ind. 

5 
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Bezugszeichenliste 

1 Sendeapplikation (MMS User Agent A = UAA) 

2 Senderseitiges Netzwerkelement (MMS Relay/Server A = 
5 RSA) 

3 MMS Speicher A (MMS Server A) 

4 MMS-Umgebung (= MMSE; eines MMS-Dienstleisters A) 

6 Offentliches Mobilnetzwerk (PLMN = Public Land Mobile 
Network) 

10 7 VAS-Applikation (VAS = Value Added Service) 

11 Empf angsapplikation (MMS User Agent B = UAB) 

12 Empf angerseitiges Netzwerkelement (MMS Relay/Server B = 
RSB) 

13 MMS Speicher B (MMS Server B) 

15 14 MMSE-Umgebung (= MMSE; eines MMS-Dienstleisters B) 

20 IP - Internet Protocol 

21 Legacy-Nachrichtensystem (Legacy Messaging System) 

22 Einf achpostubertragungsprotokoll (SMTP = Simple Mail 
Transfer Protocol ) 



20 
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PATENT AN S P RUCHE 

1. Verfahren zum Zugreifen auf eine erste Nachricht (MM A ) , 
insbesondere eine multimediale Nachricht (MM) vorzugsweise 
5 vom MMS-Typ, wobei die erste Nachricht (MM A ) mittels einer 
Sendeapplikation (1) oder einer netzwerkseitigen VAS- 
Applikation (7) an eine Empf angsapplikation (11) gesendet 
wird, dadurch gekennzeichnet , dafe eine zweite Nach- 
richt (MM B ) mit einem Manipulationsauf trag zur Manipulation 
10 der ersten Nachricht (MM A ) erstellt, versendet, empfangen, 

weitergeleitet und/oder verarbeitet wird, um einen manipulie- 
renden Zugriff auf die erste Nachricht (MM A ) zu veranlassen 
oder zu vermitteln. 

15 2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, da£ 

die erste Nachricht (MM A ) und die zweite Nachricht (MM B ) liber 
Funk, liber Mobilf unksysteme , zwischen Mobilf unksystemen, ins- 
besondere Inter-Operator- IP-backbone , zwischen Mobilf unknet- 
zen und anderen Ma chr i cht en - Net z en , insbesondere Internet-E- 

20 mail, und/oder iiber das Internet versendet werden. 

3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch ge- 
kennzeichnet, daS die erste Nachricht (MM A ) und die zweite 
Nachricht (MM B ) iiber mindestens ein senderseitiges Netzwerk- 
25 element (2) eines Dienstanbieters (Dienstanbieter A) und min- 
destens ein empf angerseitiges Netzwerkelement (12) eines 
Dienstanbieters (Dienstanbieter B) an die Empf angsapplikation 
(11) gesendet wird. 

30 4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, da£ 

das mindestens eine senderseitige Netzwerkelement (2) und das 
mindestens eine empf angerseitige Netzwerkelement (12) dem Zu- 
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standigkeitsbereich (4) eines einzigen Dienstanbieters 
(Dienstanbieter A) angehoren oder auch identisch sind* 

5. Verfahren nach einem der vorhergehenden Anspruche, da- 
5 durch gekennzeichnet , daS die Sendeapplikation (1) und die 

Empf angsapplikation (11) identisch sind. 

6. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet, da£ der manipulierende Zugriff auf die 

10 erste Nachricht (MM A ) auf einem senderseitigen Netzwerkele- 
ment (2), auf einem . empf angerseitigen Netzwerkelement (12) 
und/oder auf der Empf angsapplikation (11) erf olgt . 

7. Verfahren nach einem der vorhergehenden Anspruche, da- 

15 durch gekennzeichnet, daE der Manipulationsauf trag den Ruck- 
ruf bzw. das Loschen der ersten Nachricht (MM A ) umfaSt. 

8. Verfahren nach einem der Anspruche 1 bis 6, dadurch ge- 
kennzeichnet, da£ der Manipulationsauf trag das Andern der 

20 ersten Nachricht (MM A ) umfa£t, insbesondere durch Ersetzen 
der ersten Nachricht (MM A ) durch die zweite Nachricht (MM B ) . 

9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, daiS 
bei Nichtunterstiitzung des Andern-Auf trages seitens mindes- 

25 tens eines der beteiligten MMS-Umgebungen (4, 14) der Dienst- 
anbieter, die zweite Nachricht (MM B ) als gewohnliche Nach- 
richt der Empf angsapplikation (11) zugestellt wird, wobei der 
Absender vorzugsweise hieruber informiert wird. 

30 10. Verfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, 
da£ die zweite Nachricht (MM B ) im Falle eines Anderungsauf - 
trages entweder im PUSH-Modus (Druck-/Bring-Modus) oder im 
PULL-Modus (Zieh- /Hoi -Modus) heruntergeladen wird. 
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11. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, da£ die zweite Nachricht (MM B ) mit dem 
Manipulationsauf trag an den Empfanger der ersten Nachricht 

5 (MM A ) vers chi ckt wird, wobei zur Kennung bzw. I dent if izierung 
der ersten Nachricht (MM A ) vorzugsweise deren I dent if ikati- 
onsnummer (ID1) verwendet wird, welche die erste Nachricht 
(MM A ) zwischen der Sendeapplikation (1) oder der VAS- 
Applikation (7) und einem senderseitigen Netzwerkelement (2) 
10 eindeutig kennzeichnet . 

12. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet , da£ beim Versenden einer Nachricht ei- 
nem senderseitigen Netzwerkelement (2) von der Sendeapplika- 

15 tion (1) oder der VAS-Applikation (7) eine oder mehrere der 
folgenden Informationen bereitgestellt werden: 

- Kennzeichnung, dafi es sich bei der Nachricht (MM B ) urn einen 
Manipulationsauf trag handelt; 

- Identif ikationsnummer der ersten Nachricht (MM A ) , die mani- 
20 puliert werden soil; 

- Information, daiS der Absender eine Ruckmeldung uber den 
Ausgang der von ihm initiierten Manipulation anf ordert . 

13. Verfahren nach einem der vorhergehenden Anspriiche, da- 
25 durch gekennzeichnet, daS der Sendeapplikation (1) oder der 

VAS-Applikation (7) von einem senderseitigen Netzwerkelement 
(2) die Information bereitgestellt wird, ob dieses Netzwerk- 
element (2) die Manipulation gemaiS den vorhergehenden Anspru- 
chen unterstiitzt und/oder ob der Manipulat ions -Auf trag von 
30 dem Dienstanbieter (Dienstanbieter A) der Sendeapplikation 
(1) oder der VAS-Applikation (7) angenommen wurde. 
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14. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, daS bei Zugehorigkeit der Sendeapplika 
tion (1) bzw. der VAS-Applikation (7) und der Empf angsappli- 
kation (11) zu unterschiedlichen MMS-Umgebungen (MMSE A , 
MMSE B ) von Dienstanbietern einem empf angerseitigen Netzwerk- 
element (11) von einem senderseitigen Netzwerkelement (1) ei 
ne oder mehrere der folgenden Inf ormationen bereitgestellt 
werden : 

- Kennzeichnung, date es sich bei der zweiten Nachricht (MM B ) 
um einen Manipulationsauf trag handelt; 

- Identif ikationsnummer der ersten Nachricht (MM A ) , die mani- 
puliert werden soli; 

- Information, dafi der Absender eine Ruckmeldung uber den 
Ausgang der von ihm initiierten Manipulation anfordert. 

15. Verfahren nach einem der vorhergehenden Anspruchen, da- 
durch gekennzeichnet , da£ Netzwerkelemente (2, 12) von ver- 
schiedenen Dienstanbietern (Dienstanbieter A, Dienstanbieter 
B) eine eineindeutige , umkehrbare Umwandlung von auf die ers- 
te und/oder die zweite Nachricht bezogene Identif ikationsnum- 
mem (ID1, ID3 ; ID4 , ID6, IDS) vornehmen und die entsprechen- 
den Inf ormationen vorzugsweise verwalten. 

16. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, dafi im Falle eines Manipulationsauf - 
trags, insbesondere einschlieSlich eines Loschungsbef ehls , 
bei noch nicht erfolgter Benachrichtigung der Empf angsappli- 
kation (11) uber die erste Nachricht (MM A ) diese erste Nach- 
richt (MM A ) in der MMS-Umgebung (MMSE A ) des senderseitigen 
Dienstanbieters (Dienstanbieter A) oder im Zustandigkeitsbe- 
reich (MMSE B ) des empf angerseitigen Dienstanbieters (Dienst- 
anbieter B) manipuliert, insbesondere geloscht, wird, wobei 
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bevorzugt die Empf angsapplikation (11) uber die Manipulation 
nicht informiert wird. 

17. Verfahren nach einem der Anspruche 1 bis 15, dadurch ge- 
5 kennzeichnet, daS im Falle eines Manipulationsauf trags bei 

auf der Empf angsseite erfolgter Benachrichtigung, aber noch 
nicht heruntergeladener erster Nachricht (MM A ) diese erste 
Nachricht (MM A ) in der MMS-Umgebung (MMSE B ) des empf angssei- 
tigen Dienstanbieters (Dienstanbieter B) manipuliert wird, 
10 wobei die Empf angsapplikation (11) uber die Manipulation und 
uber deren Zeitpunkt vorzugsweise informiert wird. 

18. Verfahren nach einem der Anspruche 1 bis 15, dadurch ge- 
kennzeichnet , da£ im Falle eines Manipulationsauf trags bei 

15 auf der Empf angsseite erfolgter Benachrichtigung, aber noch 
nicht heruntergeladener erster Nachricht (MM A ) diese erste 
Nachricht (MM A ) in der MMS-Umgebung (MMSE A ) des senderseiti- 
gen Dienstanbieters (Dienstanbieter A) manipuliert wird, wo- 
bei die Empf angsapplikation (11) uber die Manipulation vor- 

20 zugsweise nicht informiert wird. 

19. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet , dafi der Empf angsapplikation (11) von 
einem empf angerseitigen Netzwerkelement (12) eine oder ggf . 

25 mehrere der folgenden Inf ormationen, vorzugsweise in einer 
Benachrichtigung, bereitgestellt werden : 

- Information, dafi eine lediglich angekundigte , aber noch 
nicht ausgelief erte erste Nachricht (MM A ) nicht mehr zum Her- 
unterladen bereitliegt, oder durch eine neue Nachricht (MM B ) 
30 geandert worden ist, wobei die Identif izierung der ersten 

und/oder der zweiten Nachricht (MM A , MM B ) vorzugsweise anhand 
des URI (Uniform Resource Identifier = Speicherplatz) er- 
folgt; 
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- Information, daS eine schon ausgelief erte erste Nachricht 
(MM A ) vom Absender manipuliert werden mochte, wobei die Iden- 
tifizierung der ersten Nachricht (MM A ) auf der Empf angsappli- 
kation (11) vorzugsweise anhand einer Nachrichtenref erenz er- 

5 folgt, welche vorzugsweise ein URI ist, unter desssen Spei- 
cherplatz eine Standard-Text -Nachricht des empf angerseitigen 
Dienstanbieters (Dienstanbieter B) abgespeichert ist, wobei 
die URI bevorzugt aus der Identif ikationsnummer (ID1) der 
ersten Nachricht (MM A ) oder von einem empf angerseitigen Netz- 
10 werkelement (12) festgelegten zweiten Identif ikationsnummer 
(ID2) zusammengesetzt ist; 

- Mitteilung uber die Manipulation der ersten Nachricht (MM A ) 
auf Seiten eines Dienstanbieters (Dienstanbieter A oder B) ; 

- Mitteilung uber die Durchftihrung einer Manipulation und bei 
15 Anforderung des Empfangers uber das Nichtzurverf ugungstehen 

der manipulierten Nachricht; 

- Kennzeichnung, daS die zweite Nachricht (MM B ) einen Manipu- 
lationsauf trag enthalt, der auf der Empf angsapplikat ion (11) 
ausgefuhrt werden soli; 

20 - Information, welche bereits ausgelief erte Nachricht (MM A ) 
manipuliert werden soil; 

- Information, wann die Manipulation ausgefuhrt wurde,-' 

- Information, da£ die ausgelief erte zweite Nachricht (MM B ) 
eine nachtraglich geanderte Nachricht ist; 

25 - Information, welcher Art die vorzunehmende Manipulation 
ist . 

20. Verfahren nach einem der vorhergehenden Anspruche, da~ 
durch gekennzeichnet , daS einem empf angerseitigen Netzwerk- 
30 element (12) von der Empf angsapplikation (11) nach ihrer Be- 
nachricht igung iiber die zweite Nachricht (MM B ) mindestens ei- 
ne der folgenden Inf ormationen bereitgestellt werden: 
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- Information, ob die Empf angsapplikat ion (11) verstanden 
hat, da£ die zuvor lediglich angekundigte erste Nachricht 
(MM A ) erfolgreich manipuliert wurde; 

- Information, ob die Manipulation der bereits heruntergela- 
denen ersten Nachricht (MM A ) erfolgreich ausgefuhrt werden 
konnte ; 

- Information, ob der Empfanger daruber informiert wurde 
und/oder zugestimmt hat, da£ die bereits heruntergeladene 
Nachricht (MM A ) manipuliert wurde; 

- bei MiSerfolg der Grund fur die nicht erfolgreiche Ausfuh- 
rung ; 

- Information, ob im Falle eines Anderungsauf trags die Ande- 
rung der bereits heruntergeladenen ersten Nachricht (MM A ) au- 
tomat isch (PUSH-Modus) oder auf Veranlassung des Empf angers 
(PULL -Modus) durchgefiihrt wurde; 

- Information, welcher Art die vorzunehmende Manipulation 
ist . 

21. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet, daS bei Zugehorigkeit der Sendeapplika- 
tion (1) bzw. der VAS-Applikation (7) und der Empf angsappli - 
kation (11) zu unterschiedlichen MMS-Umgebungen (MMSE A/ 
MMSEb) von Dienstanbietern (Dienstanbieter A, Dienstanbieter 
B) einem senderseitigen Netzwerkelement (2) von einem empf an - 
gerseitigen Netzwerkelement (12) eine oder mehrere der fol- 
genden Inf ormationen bereitgestellt werden: 

- Information, ob der Manipulationsauf trag erfolgreich ausge- 
fuhrt werden konnte; 

- bei MiSerfolg der Grund fur die nicht erfolgreiche Ausfuh- 
rung ; 

- Information, wann der Manipulationsauf trag ausgefuhrt wur- 
de; 
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- Information, ob der Manipulationsauf trag automatisch ausge- 
fiihrt wurde/ 

- Information, ob der Empf anger iiber die Manipulation infor- 
miert wurde und/oder der Manipulation zugestimmt hat und/oder 

5 die Manipulation vom Empf anger veranlaEt wurde; 

- Information, daS die bereits heruntergeladene erste Nach- 
richt (MM A ) manipuliert wurde, oder die erste Nadir icht (MM A ) 
vor einer Anderung noch nicht heruntergeladen war; 

- Interims -Identif ikationsnummer (ID3) der Nachricht (MM A ) , 
10 die manipuliert wurde; 

- Information, welcher Art die vorgenommene Manipulation ist. 

22. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet , daS der Sendeapplikation (1) oder der 
15 VAS-Applikation (7) von einem senderseitigen Netzwerkelement 
(2) eine oder mehrere der folgenden Informationen bereitge- 
stellt werden : 

- Information, ob der Manipulationsauf trag erfolgreich ausge- 
f uhrt wurde ; 

20 - bei MiSerfolg der Grund fur die nicht erfolgreiche Ausfuh- 
rung ; 

- Information, da6 eine Manipulation auf grund eines Weiter- 
leitens der ersten Nachricht (MM A ) an eine unbekannte Adresse 
nicht durchgefuhrt werden konnte; 

25 - Information, wann der Manipulationsauf trag ausgefuhrt wur- 
de; 

- Information, ob der Manipulationsauf trag automatisch durch- 
gefuhrt wurde; 

- Information, ob der Empf anger uber die Manipulation infor- 
30 miert wurde und/oder oder der Manipulation zugestimmt hat 

und/oder der Empf anger diese initiiert hat; 
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- Information, dafi die bereits heruntergeladene Nachricht 
(MM A ) manipuliert wurde, oder die erste Nachricht (MM A ) vor 
einer Anderung noch nicht ausgeliefert war; 

- Identif ikationsnummer (ID1) der Nachricht (MM A ) , die mani- 
5 puliert wurde. 

23. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet , daS die zweite Nachricht (MM B ) mindes- 
tens ein von der Sendeapplikation (1) oder der VAS- 

10 Applikation (7) beigeordnetes Inf ormationselement umfafit, 

welches mindestens eine Bedingung fur die Ausfuhrung des ma~ 
nipulierenden Zugriffs enthalt. 

24. Verfahren nach Anspruch 23, dadurch gekennzeichnet, da£ 
15 das mindestens eine Inf ormationselement den manipulierenden 

Zugriff entsprechend dem Bearbeitungszustand der ersten Nach- 
richt (MM A ) angibt . 

25. Verfahren nach Anspruch 23 oder 24, dadurch gekennzeich- 
20 net, dag mindestens eine der folgenden Bedingungen von der 

Sendeapplikation (1) oder der VAS -Applikation (7) mittels des 
mindestens einen Inf ormationselement festgelegt wird: 

- Manipulation der ersten Nachricht (MM A ) nur, wenn die erste 
Nachricht (MM A ) noch auf dem Server liegt und der Empfanger 

25 noch nicht uber diese Nachricht (MM A ) benachrichtigt wurde; 

- Manipulation der ersten Nachricht auch dann, wenn die Be- 
nachrichtigung gesendet wurde, aber die erste Nachricht (MM A ) 
noch nicht heruntergeladen wurde; 

- Manipulation der ersten Nachricht (MM A ) , wenn der Empfanger 
30 diese noch nicht geoffnet bzw. gelesen hat ; 

- Manipulation der ersten Nachricht (MM A ) unabhangig vom Be- 
arbeitungsgrad . 
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26. Verfahren nach einem der Anspriiche 23 bis 25, dadurch 
gekennzeichnet , daS dem Inf ormationselement ein Voreinstel- 
lungswert (Default Value) zugeordnet wird, der fur eine Mani- 
pulation entsprechend dem Voreinstellungswert bei nicht naher 
prazisierter Bedingung steht. 

27. Verfahren nach einem der Anspriiche 23 bis 26, dadurch 
gekennzeichnet, daS mindestens einer der an der Ubermittlung 
der ersten und der zweiten Nachricht {MM A , MM B ) beteiligten 
Dienstanbieter (Dienstanbieter A und/oder Dienstanbieter B) 
den Manipulationsauf trag auf die eigene oder auf bestimmte 
Domanen anderer Dienstanbieter begrenzt, vorzugsweise anhand 
einer Identif izierung des Empf angers (Rufnummer, Mailadresse, 
...) oder durch Benutzung einer zusatzlichen Kennzeichnung. 

28. Verfahren nach einem der Anspriiche 23 bis 27, dadurch 
gekennzeichnet, daS der den Manipulationsauf trag enthaltenden 
zweiten Nachricht (MM B ) , die von der Sendeapplikation (1) o- 
der der VAS-Applikation (7) an ein senderseitiges Netzwerk- 
element (2) gesendet wird, eine der folgenden Bedingungen zum 
Ausfuhren der Manipulation der ersten Nachricht (MM A ) beige- 
ordnet wird: 

- Manipulation nur vor Benachrichtigung des Empf angers; 

- Manipulation nur vor dem Herunterladen, auch nach dem Ver- 
sand einer Benachrichtigung; 

- Manipulation nur, wenn die erste Nachricht (MM A ) noch nicht 
geoffnet bzw. gelesen wurde; 

- Manipulation unabhangig vom Bearbeitungszustand der ersten 
Nachricht (MM A ) . 

29. Verfahren nach einem der Anspriiche 23 bis 28, dadurch 
gekennzeichnet, da£ der Sendeapplikation (1) oder der VAS- 
Applikation (7) von einem senderseitigen Net zwerke lenient (2) 
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bei der Bestatigung nach dem Versenden der ersten oder zwei- 
ten Nachricht (MM A/ MM B ) mitgeteilt wird, ob dieses Netzwerk- 
element (2) die besagte bedingte Manipulation unterstiitzt 
und/oder ob der bedingte Manipulations-Auf trag von dem sen- 
derseitigen Dienstanbieter (Dienstanbieter A) angenommen wur- 
de . 

30. Verfahren nach einem der Anspriiche 23 bis 29, dadurch 
gekennzeichnet , da£ bei Zugehorigkeit der Sendeapplikation 

(I) bzw. der VAS-Applikation (7) und der Empf angsapplikation 

(II) zu unterschiedlichen MMS-Umgebungen (MMSE A/ MMSE B ) von 
Dienstanbietern (Dienstanbieter A, Dienstanbieter B) einem 
empf angerseitigen Netzwerkelement (12) von einem senderseiti- 
gen Netzwerkelement (2) eine oder mehrere der folgenden Be- 
dingungen hinsichtlich der Manipulation der ersten Nachricht 

(MM A ) durch die zweite Nachricht (MM B ) ubermittelt werden: 

- Manipulation nur vor Benachrichtigung des Empf angers; 

- Manipulation nur vor dem Herunter laden, auch nach dem Ver- 
sand einer Benachrichtigung; 

- Manipulation nur, wenn die erste Nachricht (MM A ) noch nicht 
geoffnet bzw. gelesen wurde; 

- Manipulation unabhangig vom Bearbeitungszustand der ersten 
Nachricht (MM A ) . 

31. Verfahren nach einem der Anspriiche 23 bis 30, dadurch 
gekennzeichnet, da£ der Empf angsapplikation (11) von einem 
empfangerseitigen Netzwerkelement (12) eine oder mehrere der 
folgenden Bedingungen hinsichtlich der Manipulation der ers- 
ten Nachricht (MM A ) durch die zweite Nachricht (MM B ) iibermit- 
telt werden, vorzugsweise bei der Benachrichtigung liber die 
eingetrof f ene zweite Nachricht (MM B ) : 

- Manipulation nur vor Benachrichtigung des Empf angers; 

- Manipulation nur vor dem Herunterladen, auch nach dem Ver- 
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sand einer Benachrichtigung; 

- Manipulation nur, wenn die erste Nachricht (MM A ) noch nicht 
geoffnet bzw. gelesen wurde; 

- Manipulation unabhangig vom Bearbeitungszustand der ersten 
5 Nachricht (MM A ) . 

32. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, daS das Versenden, Empfangen und Mani- 
pulieren der Nachrichten (MM) , einschlieSlich des bedingten 

10 Manipulierens , mittels WAP-Nachrichten (Wireless Application 
Protocol ) erf olgt . 

33. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, da6 die Manipulationsauf trage durch Mo- 

15 difizieren von vorhandenen Kopf-Feldern (X-Mms- Status ; M-Mms- 
Suppor ted- Feature) und/oder durch Hinzufugen von zusatzlichen 
Kopf-Feldern {X-Mms -Recall -ID; X-Mms -Recalled-URI ; X-Mms- 
Replace- ID; X-Mms - Replaced -URI ; X-Mms -Supported- Feature ; X- 
Mms -Date- Of-Execu ti on ; X-Mms -Reques t -Report ; X-Mms - Ori ginal - 

20 Message -Status; X-Mms - Ori ginal -Message - ID ; X-Mms -Recal 1 - Cond ; 
X-Mms -Replace-Cond; X-Mms -Recall -Status ; X-Mms -Replace - 
Status; X-Mms -Operation- Status) in geeigneten WAP- 
Nachrichten, insbesondere solche nach dem WAP- 

MMSEncapsulation Standard und insbesondere in mindestens eine 
25 der WAP-Nachrichten M-Send. req r M-Send.conf , M- 

Notification. ind, M~Noti£yResp . req, M-Retrieve . conf , M- 
Acknowledge. ind, M-Delivery . ind, implementiert werden. . 

34. Verfahren nach einem der vorhergehenden Anspriiche, da- 
30 durch gekennzeichnet, daS die erste Nachricht (MM A ) fii r eine 

Ruckmeldung iiber das Ergebnis des Manipulationsauf trags an- 
hand der Identif ikationsnummer (ID4) der zweiten Nachricht 
(MM B ) sowie der Transaktions- Identif ikationsnummern der ent- 
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sprechenden WAP -Nachricht en, oder anhand eines zusatzlichen 
Kopf-Feldes identif iziert wird, wobei Feld-Werte des neuen 
Kopf-Feldes die Identif ikationsnummer (ID1) der ersten Nach- 
richt (MM A ) enthalten. 

35. Telekommunikationseinrichtung, insbesondere zur zumin- 
dest teilweisen Durchf uhrung des Verfahrens nach einem der 
vorhergehenden Anspruche, mit Mitteln zum Erstellen, Versen- 
den, Empfangen und/oder Verarbeiten einer ersten Nachricht 
(MM A ) , insbesondere einer multimedialen Nachricht vorzugswei- 
se vom MMS-Typ, gekennzeichnet durch Mittel zum Erstel- 
len, Versenden ; Empfangen und/oder Verarbeiten einer zweiten 
Nachricht (MM B ) , wobei die zweite Nachricht (MM B ) einen unbe- 
dingten oder bedingten Manipulationsauf trag zum Manipulieren 
der zuvor gesendeten ersten Nachricht (MM A ) umf a£t . 

36. Telekommunikationseinrichtung nach Anspruch 35, gekenn- 
zeichnet durch eine Sendeapplikation (1) oder eine VAS- 
Applikation (7) sowie einer mit diesen Applikationen (1, 7) 
verbundenen oder verbindbaren Sendeeinheit . 

37. Telekommunikationseinrichtung nach Anspruch 35 oder 36, 
gekennzeichnet durch eine Empf angsapplikation (11) sowie ei- 
ner mit der Empf angsapplikation (11) verbundenen oder ver- 
bindbaren Empf angseinheit . 

38. Telekommunikationseinrichtung nach einem der Anspruche 
3 5 bis 37, gekennzeichnet durch eine Prozessoreinheit zum 
Auswerten von Benachrichtigungen von einem senderseitigen 
Netzwerkelement (2) hinsichtlich der Unterstiitzung von unbe- 
dingten und/oder bedingten Manipulationsauf tragen, des er- 
folgreichen oder erfolglosen Ausfuhrens des Manipulationsauf- 
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trages und/oder der Griinde fur ein erfolgloses Ausfuhren des 
Manipulationsauf trages . 

39. Telekommunikationseinrichtung nach einem der Anspruche 
35 bis 38, gekennzeichnet durch eine Prozessoreinheit zum 
Auswerten von Benachrichtigungen seitens eines empf anger sei- 
tigen Netzwerkelements (12) uber Informationen hinsichtlich 
der Ausfuhrung des unbedingten oder bedingten Manipulations- 
auf trages . 



40. Telekommunikationseinrichtung nach Anspruch 39, gekenn- 
zeichnet durch eine Sendeeinheit zum Senden von Benachrichti- 
gungen an ein empf angerseitiges Metzwerkelement (12) hin- 
sichtlich des erfolgreichen oder erfolglosen Ausfiihrens des 
Manipulationsauftrages und/oder der Griinde fur ein erfolglo- 
ses Ausfuhren des Manipulationsauftrages. 

41. Telekommunikationseinrichtung nach einem der Anspruche 
35 bis 40, dadurch gekennzeichnet , dafi es als Mobiltelefon 
mit einer Sende- und einer Empf angseinheit ausgebildet ist. 

42. Telekommunikationseinrichtung nach einem der Anspriiche 
35 bis 40, dadurch gekennzeichnet, daS es als Netzwerkelement 
ausgebildet ist, auf der sich eine VAS-Applikation (7) befin- 
det . 

43. Telekommunikationseinrichtung nach einem der Anspruche 
35 bis 42, dadurch gekennzeichnet, daiS die Mittel derart aus- 
gebildet sind, daS sie die Verarbeitung von WAP-Nachrichten, 
insbesondere solchen nach dem WAP-MMSEncapsulation Standard 
und insbesondere die WAP-Nachrichten M-Send. reg, M - Send . con f , 
M-Notificcition.±nd, M-Not±fyResp.req, M-Retrieve . conf , M- 
Acknowledgre.lnd, M-Delivery . ind, mit entsprechend deri i m Rah- 
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men der Manipulationsauf t rage auszutauschenden Informationen 
modi fizier ten Kopffeldern und/oder zusatzlichen Kopffeldern 
gestatten . 

44 . Telekommunikationseinrichtung nach einem der Anspriiche 
35 bis 43, gekennzeichnet durch Mittel zum Erzeugen eines In- 
format ionselements sowie Mittel zum Zuordnen dieses Informa- 
tionselements durch die Sendeapplikation (1) oder die VAS- 
Applikation (7) zur zweiten Nachricht (MM B ) , wobei das Infor- 
mationselement mindestens eine Bedingung fur die Ausfiihrung 
des manipulierenden Zugriffs enthalt . 

45. Telekommunikationseinrichtung nach Anspruch 44, gekenn- 
zeichnet durch Mittel zum Ausfuhren des Manipulationsauf - 
trags . 

46. Netzwerkelement (2; 12), insbesondere eines Funkkommuni- 
kationssystems und insbesondere zur netzwerkseitigen Durch- 
fuhrung der Verf ahrensschritte nach einem der Anspriiche 1 bis 
34, mit Mitteln zum Empfangen und Weiterleiten von einer von 
Telekommunikationseinrichtungen gemaE einem der Anspriiche 3 5 
bis 45 gesendeten ersten Nachricht (MM A ) , insbesondere einer 
multimediale Nachrichtn, vorzugsweise vom MMS-Typ, gekenn- 
zeichnet durch Mittel zum Empfangen, Verarbeiten 
und/oder Weiterleiten einer zweiten Nachricht (MM B ) mit einem 
Manipulationsauftrag, welcher sich auf die empfangene und 
ggf . schon weitergeleitete erste Nachricht (MM A ) bezieht, urn 
einen manipulierenden Zugriff auf die erste Nachricht (MM A ) 

zu veranlassen oder zu vermitteln. 

47. Netzwerkelement nach Anspruch 46, gekennzeichnet durch 
Mittel zum Empfangen und Weiterleiten und/oder Erzeugen sowie 
Versenden von Mitteilungen an ein anderes Netzwerkelement 
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(12; 2) und/oder eine senderseitige und/oder eine empf anger- 
seitige Empf angsapplikation (1; 11) , wobei diese Mitteilungen 
die von dem Absender festgelegten Bedingungen fur die Ausfiih- 
rung eines in der zweiten Nachricht (MM B ) spezif izierten Ma- 
nipulationsauf trages , des erf olgreichen oder erfolglosen Aus- 
fuhrens des bedingten Manipulationsauf trages und/oder der 
Griinde fur ein erfolgloses Ausfuhren des bedingten Manipula- 
tionsauf trages betreffen. 

48. Netzwerkelement nach Anspruch 46 oder 47, gekennzeichnet 
durch Mittel zum Ausfuhren des Manipulationsauf trags . 

49. Netzwerkelement nach Anspruch 48, dadurch gekennzeich- 
net, dag die erste Nachricht (MM A ) auf einem Netzwerkelement 
(2; 12) und/oder auf einer Empf angsapplikation (11) einer 
Empf angseinheit manipulierbar ist, insbesondere loschbar 
und/oder anderbar . 

50. Netzwerkelement nach einem der Anspriiche 46 bis 49, da- 
durch gekennzeichnet, dafi die Mittel zum Empfangen, Verarbei- 
ten und/oder Weiterleiten der zweiten Nachricht (MM B ) von 
WAP-Nachrichten, insbesondere solche nach dem WAP- 
MMSEncapsulation Standard und insbesondere den WAP- 
Nachrichten M-Send.req, M-Send. conf , M-Notification. ind, M- 
NotifyResp.req, M-Retrieve . conf , M- Acknowledge . ind und M- 
Delivery. ind mit entsprechend den im Rahmen der Manipulati- 
onsauftrage auszutauschenden Inf ormationen modif izierten 
Kopf-Feldern und/oder zusatzlichen Kopf -Feldern, Gebrauch ma- 
chen . 

51. Sof twareprogramm, welches auf einer Vorrichtung mit ei- 
nem Prozessor, insbesondere einer Telekommunikationseinrich- 
tung und insbesondere einer solchen gemaS einem der Anspriiche 
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35 bis 45, oder einem Netzwerkelement , insbesondere eines 
solchen gemaS einem der Anspruche 46 bis 50, derart ablaufen 
kann, daS das Sof twareprogramm mitsamt der Vorrichtung die 
Verf ahrensschritte auf der Seite der Vorrichtung gemaS einem 
5 der Anspruche 1 bis 34 ausfuhrt oder veranlafit. 

52. Sof twareprogramm, welches in eine Vorrichtung mit einem 
Prozessor , insbesondere einer Telekommunikationseinrichtung 
und insbesondere einer solchen gemaE einem der Anspruche 35 
10 bis 4 5 oder einem Netzwerkelement und insbesondere eines sol- 
chen gemafi einem der Anspruche 4 6 bis 50, ladbar ist, so dafi 
die derart programmierte Vorrichtung einschliefilich des Pro- 
zessors fahig oder angepaSt ist, die Verf ahrensschritte gemaS 
einem der Anspruche 1 bis 34 auszufuhren oder zu veranlassen. 
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FIG 4 



1 




2 




12 



Abschicken 
von MM a 
(ID1) ' 



Abschicken 
von MMb (ID4) 
Referenz: ID1 ~- 



/ 



\ 



Statusmeldung 
- MM B (ID4) 



i 

/ 



Weiterleiten 
von MM A (ID3)- 



Weiterleiten 
von MMg (ID6) 
Referenz: ID3 



A 



\ 



Statusmeldung" 
' MMg (ID6) 



" Benachrichtigung 
uber MM A (UR1 1). 

Auslieferung 
von MMa(ID2)_ 



- Benachrichtigung 
uber MM B (URI 2) 
Referenz: ID2 - 

^ Auslieferung 
von MMg (ID5) 
Referenz: ID2 ^ 



Auslieferungs- 
■ bestatigung 



WO 02/063839 



4/11 



PCT/EP02/00571 



FIG 5 

X-Mms~Recall-ID: (0x7F) 

Recall-ID-Value (Ruckruf-ID-Wert) = Text-String 

X-Mms-Recalled-URI: (0x80) 

Recalled-URI-Value (Zuriickgerufen-URI-Wert) = Text-String 

X-Mms-Replace-ID: (0x81) 

Replace-ID-Value (Andern-ID-Wert) = Text-String 

X-Mms-Replaced-URI: (0x82) 

Replaced-URI-Value (Geandert-URI-Wert) = Text-String 

i 

X-Mms-Supported-Feature: (0x83) 

Supported-Feature-Value (Unterstutzung-Merkmal-Wert) = Recall 

I Replace I no Support 

(Ruckruf / Andem / keine Unterstutzung) 
recall (Ruckruf) =<Octet128> 
replace (Andern) = <Octet 129> 
no Support (keine Unterstutzung) = <Octet 130> 

X-Mms-Date-of-Execution: (0x84) 

Date-Of-Execution-Value (Zeitpunkt-Der-Ausfiihrung) = Longinteger 
In seconds from 1970-01-01, 00:00:00 GMT 
(In sekunden von 1970-01-01, 00:00:00 GMT)) 

X-Mms-Request-Report: (0x85) 
Request-Report-Value = Yes I No (Ja / Nein) 
Yes(Ja) = Octet 128> 
No (Nein) = <Octet 129> 
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FIG6A 

X-Mms-Status: (0x14) 

Status-Value = Expired I (Abgelaufen) 

Retrieved I (Heruntergeladen) 

Rejected I (Zuriickgewiesen) 

Deferred I (Verschoben) 

Recall successful I (Ruckruf erfolgreich) 

Recall failed I (Ruckruf fehlgeschlagen) 

Replace successful (Andern erfolgreich) 

Replace failed I (Andern fehlgeschlagen) 

Recall feature supported I 

(Ruckruf-Merkmal unterstutzt) 

Replace feature supported 

(Anderungs-Merkmal-Unterstutzung) 
Expired (Abgelaufen) = <Octet 128> 
Retrieved (Heruntergeladen) = <Octet 129> 
Rejected (Zuriickgewiesen) = <Octet 130> 
Deferred (Verschoben) = <Octet 131> 
Recall successful (Ruckruf erfolgreich) = <Octet 132> 
Recall failed (Ruckruf fehlgeschlagen) = <Octet 133> 
Replace successful (Andern erfolgreich) = <Octet 134> 
Replace failed (Andern fehlgeschlagen) = <Octet 135> 
Recall feature supported (Ruckruf-Merkmal unterstutzt) = <Octet 136> 
Replace feature supported (Anderungs-Merkmal-Unterstutzung) = <Octet 137> 
Recall successful, before notification (Ruckruf erfolgreich, 

vor Benachrichtigung) = <Octet 138> I 
Recall successful, before download (Ruckruf erfolgreich, vor 

dem Herunterladen) = Octet 139> I 
Recall successful, before MM has been read (Ruckruf 

erfolgreich, bevor MM gelesen wurde) = <Octet 140> I 
Recall successful, after MM has been read (Ruckruf 

erfolgreich, nachdem MM gelesen wurde) = <Octet 141 > 
Recall failed, since notification has been sent (Ruckruf 

fehlgeschlagen, da Benachrichtigung versendet wurde) = <Octet 142> I 
Recall failed, since MM has been downloaded (Ruckruf 

fehlgeschlagen, da MM heruntergeladen wurde) = <Octet 143> 
Recall failed, since MM has been read (Ruckruf fehlgeschlagen, 

da MM gelesen wurde) = <Octet 144> I 
Recall failed, since MM has been deleted (Ruckruf 

fehlgeschlagen, da MM geloscht wurde) = <Octet 145> 
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FIG 6B 

Recall failed, since MM has not been found (Ruckruf 

fehlgeschlagen, da MM nicht gefunden wurde) = <Octet 146> I 
Recall failed, since MM has been forwarded (Ruckruf 

fehlgeschlagen, da MM weitergeleitet wurde) = <Octet 147> I 
Replace successful, before notification (Andern erfolgreich, 

vor Benachrichtigung) = <Octet 148> I 
Replace successful, before download (Andern erfolgreich, vor 

dem Herunterladen) = <Octet 149> I 
Replace successful, before MM has been read (Andern 

erfolgreich, bevor MM gelesen wurde) = <Octet 150> | 
Replace successful, after MM has been read (Andern 

erfolgreich, nachdem MM gelesen wurde) = <Octet 151> 
Replace failed, since notification has been sent (Ruckruf 

fehlgeschlagen, da Benachrichtigung versendet wurde) = <Octet 152> I 
Replace failed, since MM has been downloaded (Ruckruf 

fehlgeschlagen, da MM heruntergeladen wurde) = <Octet 153> I 
Replace failed, since MM has been read (Ruckruf 

fehlgeschlagen, da MM gelesen wurde) = <Octet 154> I 
Replace failed, since MM has been deleted (Ruckruf 

fehlgeschlagen, da MM geloscht wurde) = <Octet 155> 
Replace failed, since MM has not been found (Ruckruf 

fehlgeschlagen, da MM nicht gefunden wurde) = <Octet 156> I 
Replace failed, since MM has been forwarded (Ruckruf 

fehlgeschlagen, da MM weitergeleitet wurde) = <0ctet 157> 



WO 02/063839 PCT/EP02/00571 

7/11 



FIG 7 

X-Mms-Original-Message-Status: (0x86) 

Original-Message-Status-Value = 

Recall successful I (Ruckruf erfolgreich) 

Recall failed I (Ruckruf fehlgeschlagen) 

Replace successful I (Andern erfolgreich) 

Replace failed I (Andern fehlgeschlagen) 

Recall successful (Ruckruf erfolgreich) = <Octet 128> 

Recall failed (Ruckruf fehlgeschlagen) = <Octet 129> 

Replace successful (Andern erfolgreich) = <Octet 130> 

Replace failed (Andern fehlgeschlagen) = <Octet 131> 



FIG 8 



X-Mms-Original-Message-ID: (0x87) 
Original-Message-ID-Value = Text-String 
(Originai-Nachrichten-ID-Wert) 
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FIG9A 

X-Mms-Recall-Cond: (0x86) 

Recall-Cond-Value = Only before Notification (Nur vor 

Benachrichtigung) I Only before download (Nur vor dem 

Herunterladen) I Only before reading (Nur vor dem Lesen) I 

Even after reading (Auch nach dem Lesen) 

Only before Notification (Nur vor Benachrichtigung) = <Octet 128> 

Only before download (Nur vor dem Herunterladen) = <Octet 129> 

Only before reading (Nur vor dem Lesen) = <Octet 130> 

Even after reading (Auch nach dem Lesen) = <Octet 131> 

X-Mms-Replace-Cond: (0x87) 

Replace-Cond-Value = Only before Notification (Nur vor 

Benachrichtigung) I Only before download (Nur vor dem 

Herunterladen) I Only before reading (Nur vor dem Lesen) I 

Even after reading (Auch nach dem Lesen) 

Only before Notification (Nur vor Benachrichtigung) = <Octet 128> 

Only before download (Nur vor dem Herunterladen) = <Octet 129> 

Only before reading (Nur vor dem Lesen) = <Octet 130> 

Even after reading (Auch nach dem Lesen) = <Octet 131> 

X-Mms-Recall-Status: (0x88) 

Recall-Status-Value = Recall successful (Ruckruf erfolgreich) 
I Recall successful, before notification (Ruckruf erfolgreich, 
vor Benachrichtigung) I Recall successful, before download 
(Ruckruf erfolgreich, vor dem Herunterladen) I Recall 
successful, before MM has been read (Ruckruf erfolgreich, 
bevor MM gelesen wurde) I Recall successful, after MM has been 
read (Ruckruf erfolgreich, nachdem MM gelesen wurde) I Recall 
failed (Ruckruf fehlgeschlagen) I Recall failed, since 
notification has been sent (Ruckruf fehlgeschlagen, da 
Benachrichtigung gesendet wurde) I Recall failed, since MM has 
been downloaded (Ruckruf fehlgeschlagen, da MM heruntergeladen 
wurde) I Recall failed, since MM has been read (Ruckruf 
fehlgeschlagen, da MM gelesen wurde) I Recall failed, since MM 
has been deleted (Ruckruf fehlgeschlagen, da MM geloscht 
wurde) I Recall failed, Message not found (Ruckruf 
fehlgeschlagen, da Nachricht nicht gefunden wurde) I Recall 
failed, Message forwarded (Ruckruf fehlgeschlagen, Nachricht 
weitergeleitet) 
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FIG 9B 

Recall successful (Ruckruf erfolgreich) = <Octet 128> 
Recall successful, before notification (Ruckruf erfolgreich, 

vor Benachrichtigung) = Octet 129> 
Recall successful, before download (Ruckruf erfolgreich, vor 

dem Herunterladen) = Octet 130> 
Recall successful, before MM has been read (Ruckruf 

erfolgreich, bevor MM gelesen wurde) = Octet 131 > 
Recall successful, after MM has been read (Ruckruf 

erfolgreich, nachdem MM gelesen wurde) = Octet 132> 
Recall failed (Ruckruf fehlgeschlagen) = Octet 133> 
Recall failed, since notification has been sent (Ruckruf 

fehlgeschlagen, da Benachrichtigung gesendet wurde) = Octet 134> 
Recall failed, since MM has been downloaded (Ruckruf fehlgeschlagen 

da MM heruntergeladen wurde) = Octet 135> 
Recall failed, since MM has been read (Ruckruf fehlgeschlagen, 

da MM gelesen wurde) = Octet 136> 
Recall failed, since MM has been deleted (Ruckruf 

fehlgeschlagen, da MM geloscht wurde) = Octet 137> 
Recall failed, Message not found (Ruckruf fehlgeschlagen, da 

Nachricht nicht gefunden wurde) = Octet 1 38> 
Recall failed, Message forwarded (Ruckruf fehlgeschlagen, 

Nachricht weitergeleitet) = Octet 1 39> 

X-Mms-Replace-Status: (0x89) 

Replace-Status-Value = Replace successful (Andern erfolgreich) 
I Replace successful, before notification (Andern erfolgreich, 
vor Benachrichtigung) I Replace successful, before download 
(Andern erfolgreich, vor dem Herunterladen) I Replace 
successful, before MM has been read (Andern erfolgreich, bevor 
MM gelesen wurde) I Replace successful, after MM has been read 
(Andern erfolgreich, nachdem MM gelesen wurde) I Replace 
failed (Andern fehlgeschlagen) I Replace failed, since 
notification has been sent (Andern fehlgeschlagen, da 
Benachrichtigung gesendet wurde) I Replace failed, since MM has 
been downloaded (Andern fehlgeschlagen, da MM heruntergeladen 
wurde) I Replace failed, since MM has been read (Andern 
fehlgeschlagen, da MM gelesen wurde) I Replace failed, since MM 
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FIG 9C 

has been deleted (Andern fehlgeschlagen, da MM geloscht wurde) I 

Replace failed, Message not found (Andern fehlgeschlagen, 

da Nachricht nicht gefunden wurde) I Replace failed, Message forwarded 

(Andern fehlgeschlagen, Nachricht weitergeleitet) 

Replace successful (Andern erfolgreich) = <Octet 128> 

Replace successful, before notification (Andern erfolgreich, 

vor Benachrichtigung) = <0ctet 129> 
Replace successful, before download (Andern erfolgreich, vor 

dem Herunterladen) = <Octet 130> 
Replace successful, before MM has been read (Andern 

erfolgreich, bevor MM gelesen wurde) = Octet 131> 
Replace successful, after MM has been read (Andern 

erfolgreich, nachdem MM gelesen wurde) = <Octet 132> 
Replace failed (Andern fehlgeschlagen) = <Octet 133> 
Replace failed, since notification has been sent (Andern 

fehlgeschlagen, da Benachrichtigung gesendet wurde) = <Octet 134> 
Replace failed, since MM has been downloaded (Andern 

fehlgeschlagen, da MM heruntergeladen wurde) = <Octet 135> 
Replace failed, since MM has been read (Andern fehlgeschlagen, 

da MM gelesen wurde) = Octet 136> 
Replace failed, since MM has been deleted (Andern 

fehlgeschlagen, da MM geloscht wurde) = Octet 137> 
Replace failed, Message not found (Andern fehlgeschlagen, da 

Nachricht nicht gefunden wurde) = Octet 1 38> 
Recall failed, Message forwarded (Andern fehlgeschlagen, 

Nachricht weitergeleitet) = Octet 139> 

X-Mms-Operation-Status: (0x90) 

Operation-Status-Value = Operation successful (Ausfuhrung erfolgreich) I 
Operation successful, before notification (Ausfuhrung erfolgreich, vor 
Benachrichtigung) I Operation successful, before download (Ausfuhrung 
erfolgreich, vor dem Herunterladen) I Operation successful, before MM 
has been read (Ausfuhrung erfolgreich, bevor MM gelesen wurde) I 
Operation successful, after MM has been read (Ausfuhrung erfolgreich, 
nachdem MM gelesen wurde) I Operation failed (Ausfuhrung fehlgeschlagen) I 
Operation failed, since notification has been sent (Ausfuhrung fehlgeschlagen, 
da Benachrichtigung gesendet wurde) I Operation failed, since MM has been 
downloaded (Ausfuhrung fehlgeschlagen, da MM heruntergeladen wurde) I 
Operation failed, since MM has been read (Ausfuhrung fehlgeschlagen, 
da MM gelesen wurde) I 
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FIG 9D 

Operation failed, since MM has been deleted (Ausfuhrung fehlgeschlagen, 
da MM geldscht wurde) I Operation failed, Message not found (Ausfuhrung 
fehlgeschlagen, da Nachricht nicht gefunden wurde) I Operation failed, 
Message forwarded (Ausfuhrung fehlgeschlagen, Nachricht weitergeleitet) 
Operation successful (Ausfuhrung erfolgreich) = <Octet 1 28> 
Operation successful, before notification (Ausfuhrung 

erfolgreich, vor Benachrichtigung) = <Octet 1 29> 
Operation successful, before download (Ausfuhrung erfolgreich, 

vor dem Herunterladen) = Octet 130> 
Operation successful, before MM has been read (Ausfuhrung 

erfolgreich, bevor MM gelesen wurde) = <Octet 131> 
Operation successful, after MM has been read (Ausfuhrung 

erfolgreich, nachdem MM gelesen wurde) = <Octet 1 32> 
Operation failed (Ausfuhrung fehlgeschlagen) = <Octet 133> 
Operation failed, since notification has been sent (Ausfuhrung 

fehlgeschlagen, da Benachrichtigung gesendet wurde) = <Octet 134> 
Operation failed, since MM has been downloaded (Ausfuhrung 

fehlgeschlagen, da MM heruntergeladen wurde) = <Octet 135> 
Operation failed, since MM has been read (Ausfuhrung 

fehlgeschlagen, da MM gelesen wurde) = <Octet 1 36> 
Operation failed, since MM has been deleted (Ausfuhrung 

fehlgeschlagen, da MM geldscht wurde) = <Octet 137> 
Operation failed, Message not found (Ausfuhrung 

fehlgeschlagen, da Nachricht nicht gefunden wurde) = Octet 138> 
Operation failed, Message forwarded (Ausfuhrung 

fehlgeschlagen, Nachricht weitergeleitet) = Octet 139> 



FIG 10 

X-Mms-Supported-Feature: (0x83) 

Supported-Feature-Value (Unterstutztes-Merkmal-Wert) = Recall 
(Ruckruf) I Replace (Andern) I no support (keine 
Unterstutzung) I Conditional Recall (Bedingter Ruckruf) I 
Conditional Replace (Bedingtes Andern) 
recall (Ruckruf) = Octet 128> 
replace (Andern) = Octet 129> 
no support (keine Unterstutzung) = Octet 130> 
Conditional Recall (Bedingter Ruckruf) = Octet 1 31 > 
Conditional Replace (Bedingtes Andern) = Octet 132> 
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(57) Abstract: The invention relates to a method which 
enables a first message, particularly a multi-media message, 
preferably an sms type message, preferably sent via a mobile 
radio system and/or the internet to be manipulated, called 
back or altered by means of a second message sent after 
the first method. User friendliness is increased for the user 
according to said system. The invention also relates to the 
possibility of limited manipulation of a first message, as 
well as corresponding telecommunication devices, network 
elements and software programs. 

(57) Zusammenfassung: Es wird ein Verfahren 
vorgestellt, das es ermoglicht, eine vorzugsweise uber 
ein Mobilfunksystem und/oder das Internet versendete 
erste Nachricht, insbesondere eine multimediale Nachricht, 
vorzugsweise vom MMS-Typ, mittels einer zeitlich nach 
der ersten Nachricht versendeten zweiten Nachricht zu 
manipulieren, beispielsweise zuruckzurufen oder zu 
andern. Hierdurch wird die Bedienerfreundlichkeit fur 
die Nutzer solcher Systeme erhoht. AuBerdem wird die 
Moglichkeit der bedingten Manipulation einer solchen ersten 
Nachricht vorgestellt. Des weiteren werden entsprechende 
Telekommunikationseinrichtungen, Netzwerkelemente 
sowie Softwareprogramme vorgeschlagen. 
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— hinsichtlich der Berechtigung des Anmelders, ein Patent zu 
beantragen und zu erhalten (Regel 4.17 Ziffer ii) fur alle 
Bestimmungsstaaten 
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— mil internationaletn Recherche nbericht 



(88) Veroffentlichungsdatum des internationaien 

Recherchenberichts: 13. Februar2003 

Zur Erkiarung der Zweibuchstaben-Codes und der anderen 
Abkurzungen wird auf die Erklarungen ("Guidance Notes on 
Codes and Abbreviations") am Anfang jeder regularen Ausgabe 
der PCT-Gazette verwiesen. 
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